A real estate data sharing method and system based on a multi-source interface

Abstract

The application discloses a kind of real estate data sharing method and system based on multi-source interface, specifically relates to distributed transaction management technical field, for solving the problem that the state is inconsistent after the interruption of existing real estate cross-system business process due to interface transaction capability heterogeneity;Abnormal transactions are captured by monitoring interface operation execution state, successful nodes are marked based on business process topology graph, and compensation capability identifiers of source system interfaces are extracted;According to the identifier, a dynamic compensation strategy tree is constructed, and a compensation instruction sequence is reconstructed in combination with a real estate ownership dependency relationship chain and a state change atlas;Finally, the reconstructed sequence is executed in reverse order according to the topology graph, and all nodes are ensured to return to the initial state through the ownership state value comparison mechanism;Transaction compensation automation across heterogeneous systems is achieved, and the data consistency after the interruption of real estate registration business is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of distributed transaction management technology, and more specifically, to a method and system for sharing real estate data based on multi-source interfaces. Background Technology

[0002] In the field of real estate registration and management, key transactions involving property transfer, mortgage establishment and cancellation, and seizure and release often require collaboration among multiple government departments (such as real estate registration agencies, tax authorities, and courts) and financial institutions (such as banks and housing provident fund centers). These transactions typically involve a lengthy process with multiple steps. For example, "transfer of property with mortgage" requires sequentially completing steps such as canceling the old mortgage, paying taxes and fees, registering the property transfer, and establishing a new mortgage. The operation of each step relies on the information systems of the corresponding departments or institutions. These systems were built at different times, have different technical architectures, and are managed independently, forming independent systems with mutually exclusive technical architectures. To achieve joint processing of complex transactions such as "transfer of property with mortgage," it is necessary to use a data sharing platform to sequentially call interface operations across multiple source systems (such as registration databases, bank core systems, and tax platforms), forming a distributed and lengthy business process.

[0003] However, the transaction control capabilities of heterogeneous system interfaces exhibit structural differences: some systems support transaction rollback, while others only provide independent operation interfaces. When cross-system business processes experience partial success and partial failure due to network anomalies, business verification failures, or interface timeouts, the lack of a coordinated mechanism for heterogeneous compensation capabilities prevents the automatic generation and execution of an effective compensation operation sequence. This results in inconsistencies in the data status of different systems after business process interruptions (e.g., a mortgage has been cancelled but the transfer has not been completed), requiring manual intervention for repair, leading to business process stagnation and security risks related to ownership status. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a real estate data sharing method and system based on multi-source interfaces to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A method for sharing real estate data based on multi-source interfaces, comprising:

[0007] S1. Monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, capture the exception transaction identifier and business context data of the failed operation.

[0008] S2. Query the business process topology diagram based on the abnormal transaction identifier, and mark all operation nodes that have been successfully executed before the corresponding node;

[0009] S3. Based on the business process topology diagram, traverse all source system interfaces corresponding to successfully executed operation nodes and extract the compensation capability identifiers of each interface.

[0010] S4. Construct a dynamic compensation strategy tree based on the compensation capability identifier;

[0011] S5. Parse the real estate ownership dependency chain in the business context data and detect whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, reconstruct the compensation instruction sequence based on the constraint rules of the real estate status change map.

[0012] S6. Execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

[0013] Furthermore, it monitors the execution status of each interface operation in the cross-system business process, and captures the exception transaction identifier and business context data of the failed operation when the interface operation fails, including:

[0014] When an interface operation fails, the global transaction identifier is combined with the transaction identifier of the failed interface operation to generate an exception transaction identifier.

[0015] Capture business context data, which includes the set of input parameters for failed interface operations, the set of associated real estate ownership object identifiers, and a snapshot of the state of each source system at the time of the interface call;

[0016] The initial ownership status value corresponding to the set of real estate ownership object identifiers is read from the real estate registration database, and the initial ownership status value is used as the base value of the business context data.

[0017] Furthermore, based on the abnormal transaction identifier, the business process topology diagram is queried to mark all operation nodes that have been successfully executed before the corresponding node, including:

[0018] Parse the global transaction identifier from the abnormal transaction identifier;

[0019] Query the pre-stored business process topology diagram based on the global transaction identifier;

[0020] Locate the failed operation node associated with the abnormal transaction identifier in the business process topology diagram;

[0021] Traverse all operation nodes in the business process topology diagram that are preceding the failed operation node;

[0022] Mark the successfully executed operation nodes among the traversed operation nodes as successfully executed operation nodes and form a set of successfully executed operation nodes.

[0023] Furthermore, based on the business process topology diagram, the source system interfaces corresponding to all successfully executed operation nodes are traversed, and the compensation capability identifiers of each interface are extracted, including:

[0024] Obtain the set of successfully executed operation nodes marked in the business process topology diagram;

[0025] For each operation node in the set of successfully executed operation nodes, query the predefined interface metadata registry to locate the corresponding source system interface;

[0026] Extract the compensation capability identifier for each source system interface from the interface metadata registry;

[0027] The extracted compensation capability identifiers are stored in the compensation capability identifier set.

[0028] Furthermore, a dynamic compensation strategy tree is constructed based on the compensation capability identifier, including:

[0029] The type of each compensation capability identifier in the compensation capability identifier set is analyzed. The types include transaction rollback support identifier, independent reverse operation interface identifier, and manual intervention identifier.

[0030] Generate the corresponding compensation operation instruction unit based on the type of the compensation capability identifier;

[0031] According to the reverse connection relationship of the operation nodes that have been successfully executed in the business process topology diagram, the compensation operation instruction units are arranged into an initial linear sequence;

[0032] Based on the resource dependency rules between interface operations, adjust the execution order of compensation operation instruction units;

[0033] A dynamic compensation strategy tree with a tree-like topology is constructed, using resource dependencies as edges and compensation operation instruction units as nodes.

[0034] Furthermore, the compensation operation instruction unit includes a rollback function call instruction unit, a reverse operation interface sequence instruction unit, or a manual intervention alarm instruction unit.

[0035] Furthermore, the resource dependency rules between interface operations are obtained in the following way:

[0036] Parse the input and output parameters declared in the interface documents of each source system;

[0037] Extract the real estate ownership object identifiers involved in the input and output parameters;

[0038] Based on the ownership change constraints in the real estate registration business rule base, establish read / write dependencies between different interface operations on the same ownership object;

[0039] Abstract read-write dependencies into resource dependency rules.

[0040] Furthermore, the system analyzes the property ownership dependency chain in the business context data and checks whether the instruction sequence in the dynamic compensation strategy tree disrupts the topological structure of the property ownership dependency chain. If so, it reconstructs the compensation instruction sequence based on the constraint rules of the property status change graph, including:

[0041] Extract the set of real estate ownership object identifiers from the business context data;

[0042] Query the real estate register based on the set of real estate ownership object identifiers to obtain dependency relationship data between real estate ownership objects;

[0043] Construct a real estate ownership dependency chain from the dependency data;

[0044] The compensation operation instruction units in the dynamic compensation strategy tree are arranged into a compensation instruction sequence according to the execution order;

[0045] Detect whether the operation type and operation object of each instruction in the compensation instruction sequence violate the dependency constraints defined in the real estate ownership dependency chain;

[0046] When a violation of dependency constraints is detected, the missing dependency operation instruction unit is inserted into the compensation instruction sequence according to the precondition rules for state transition in the real estate status change map.

[0047] Remove the operation instruction unit from the compensation instruction sequence that causes the dependency breakage;

[0048] Generate the reconstructed compensation instruction sequence.

[0049] Furthermore, the reconstructed compensation instruction sequence is executed in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to its initial value before the business was initiated, including:

[0050] Obtain the reconstructed compensation instruction sequence;

[0051] According to the reverse order of the successfully operated nodes in the business process topology diagram, each compensation operation instruction unit in the reconstructed compensation instruction sequence is executed sequentially.

[0052] After each compensation operation instruction unit is executed, the status query function of the source system interface corresponding to the corresponding compensation operation instruction unit is called.

[0053] Obtain the current ownership status value of the operation node corresponding to the compensation operation instruction unit;

[0054] Compare the current ownership status value with the initial ownership status value in the business context data;

[0055] If the current ownership status value is inconsistent with the initial ownership status value, the corresponding compensation operation instruction unit will be re-executed until the status is consistent or the preset retry number threshold is reached.

[0056] When the preset retry count threshold is reached and the status is still inconsistent, a manual intervention alarm instruction unit is generated for the corresponding operation node.

[0057] On the other hand, the present invention provides a real estate data sharing system based on multi-source interfaces, comprising:

[0058] The transaction monitoring module is used to monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, it captures the exception transaction identifier and business context data of the failed operation.

[0059] The node marking module is used to query the business process topology diagram based on the abnormal transaction identifier and mark all operation nodes that have been successfully executed before the corresponding node.

[0060] The identifier extraction module is used to traverse all source system interfaces corresponding to successfully executed operation nodes based on the business process topology diagram and extract the compensation capability identifier of each interface.

[0061] The strategy construction module is used to build a dynamic compensation strategy tree based on the compensation capability identifier;

[0062] The sequence reconstruction module is used to parse the real estate ownership dependency chain in the business context data and detect whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, it reconstructs the compensation instruction sequence based on the constraint rules of the real estate status change map.

[0063] The state recovery module is used to execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

[0064] Compared with the prior art, the present invention has the following beneficial effects:

[0065] 1. Through deep collaboration between dynamic compensation strategy trees and ownership dependency chains, automated rollback protection for cross-system transactions of real estate is achieved. When business processes are interrupted in heterogeneous systems, multi-path compensation strategies are dynamically constructed based on interface compensation capability identifiers, and intelligent reconstruction instruction sequences of real estate ownership rules are coupled to eliminate manual repair scenarios. Especially for complex businesses, the compensation sequence is corrected in real time by parsing the ownership dependency chain (such as the constraint relationship between mortgage status and seizure status), ensuring that even if cross-system failures occur, the ownership status always conforms to the registration business rules, thus avoiding the risk of conflicting ownership status from the root.

[0066] 2. The distributed transaction compensation is transformed into a closed-loop control driven by ownership status. On the one hand, the reverse order of the business process topology is used as the baseline, and combined with the reconstructed compensation instruction sequence, the state of the multi-source system is rolled back layer by layer. On the other hand, through the ownership status value comparison and retry mechanism, the initial state is aligned at the atomic operation level, forming a strong consistency guarantee of "compensation execution-state verification". This makes the interruption recovery of cross-system operations such as tax payment and mortgage cancellation no longer dependent on the local transaction capabilities of each system, but instead builds a globally consistent compensation logic layer, which significantly improves the fault tolerance and ownership security of complex business chains. Attached Figure Description

[0067] Figure 1 This is a flowchart of a real estate data sharing method based on multi-source interfaces according to the present invention;

[0068] Figure 2 This is a schematic diagram of the structure of a real estate data sharing system based on a multi-source interface according to the present invention. Detailed Implementation

[0069] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0070] Example 1: Figure 1 This invention provides a method for sharing real estate data based on a multi-source interface, comprising:

[0071] S1. Monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, capture the exception transaction identifier and business context data of the failed operation.

[0072] S2. Query the business process topology diagram based on the abnormal transaction identifier, and mark all operation nodes that have been successfully executed before the corresponding node;

[0073] S3. Based on the business process topology diagram, traverse all source system interfaces corresponding to successfully executed operation nodes and extract the compensation capability identifiers of each interface.

[0074] S4. Construct a dynamic compensation strategy tree based on the compensation capability identifier;

[0075] S5. Parse the real estate ownership dependency chain in the business context data and detect whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, reconstruct the compensation instruction sequence based on the constraint rules of the real estate status change map.

[0076] S6. Execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

[0077] S1. Monitor the execution status of each interface operation in the cross-system business process. When an interface operation fails, capture the exception transaction identifier and business context data of the failed operation. The specific implementation is as follows:

[0078] When an interface operation fails during a cross-system business process, the transaction listener deployed on the government service bus captures this exception in real time. The transaction listener first extracts the global transaction identifier of the current business process instance. This global transaction identifier is generated by the government service bus when the business process starts and stored in the distributed transaction coordinator. Simultaneously, it obtains the transaction identifier of the failed interface operation, which is generated by the source system of the interface during the call and recorded in the interface call log. The global transaction identifier and the transaction identifier of the failed interface operation are concatenated using a connector to generate an exception transaction identifier. For example, using an underscore as the connector, if the global transaction identifier is "G20240514120300" and the failed operation transaction identifier is "OP_TAX001", then the exception transaction identifier "G20240514120300_OP_TAX001" is generated.

[0079] The specific process of capturing business context data includes: obtaining the set of input parameters for failed interface operations through an interface call interceptor, which contains all key-value pairs passed during the interface call; extracting the associated set of real estate ownership object identifiers by parsing the real estate ownership object number field in the input parameter set; and synchronously obtaining a status snapshot of each source system at the time of the interface call through the status query interface provided by each source system. The status snapshot includes the tax calculation status value field of the tax system, the business acceptance status code field of the real estate registration system, and the fund freeze transaction number field of the bank system. The status values ​​are stored in key-value pairs. For example, the tax system returns "tax_status:calculated" to indicate that the tax has been calculated, and the bank system returns "freeze_no:FF202405140008" to indicate the fund freeze operation transaction number.

[0080] The process of retrieving the initial ownership status value corresponding to the set of real estate ownership object identifiers from the real estate registration database is as follows: Based on the extracted set of real estate ownership object identifiers, a batch query request is sent to the real estate registration database. The query conditions are the list of real estate ownership object identifiers, and the query fields include core ownership attributes such as the real estate ownership status field, mortgage status flag, and seizure status field. The database executes a structured query language statement and returns a result set, which is then encapsulated into an initial ownership status value object. For example, a return value of "private" for the ownership status field indicates a private status, a mortgage status flag value of 0 indicates an unmortgaged status, and a seizure status field value of "none" indicates an unseized status. This initial ownership status value is then written as the baseline value for the business context data into the business context data storage area for subsequent status recovery comparison. The storage structure of the business context data adopts a general data exchange format.

[0081] S2. Query the business process topology diagram based on the abnormal transaction identifier, and mark all operation nodes that have been successfully executed before the corresponding node. The specific implementation is as follows:

[0082] When querying the business process topology diagram based on the abnormal transaction identifier, the global transaction identifier is first parsed from the abnormal transaction identifier. The specific parsing process is as follows: the abnormal transaction identifier is divided according to a preset delimiter used when generating the abnormal transaction identifier. For example, the abnormal transaction identifier "G20240514120300_OP_TAX001" uses an underscore as the delimiter, resulting in "G20240514120300" as the global transaction identifier. The format of this global transaction identifier is a date and time code plus a business type code, where the first 8 digits represent the date and the last 6 digits represent the time.

[0083] Based on the parsed global transaction identifier, the pre-stored business process topology graph is retrieved from the distributed storage system. The business process topology graph is stored in a graph database as a directed graph data structure, with each business process instance corresponding to an independent topology graph storage unit. The global transaction identifier is used as the primary key during the query, and the query operation returns the topology graph data for that business process instance. Each node in the topology graph contains an operation node identifier field, a source system identifier field, an operation type identifier field, and an execution status flag field. Directed edges between nodes represent the operation execution order dependencies.

[0084] Locate the failed operation node associated with the abnormal transaction identifier in the acquired business process topology diagram. The location process is as follows: extract the transaction identifier of the failed interface operation from the abnormal transaction identifier, such as "OP_TAX001"; traverse all nodes in the topology diagram, and perform a string-complete match between the operation node identifier field in the node attributes and the failed operation transaction identifier; when a match is successful, the node is the failed operation node. For example, in a topology diagram containing multiple operation nodes, if the operation node identifier of a certain node is found to be "OP_TAX001" through traversal, then it is marked as a failed operation node.

[0085] The algorithm iterates through all operation nodes in the business process topology diagram that precede the failed operation node. It employs a depth-first search strategy, starting from the failed operation node and traversing backwards through all its predecessor nodes. Specifically: it initializes an empty queue and adds the failed operation node to the queue; iteratively removes the head node of the queue and adds all its direct predecessor nodes to the queue; it records each visited node and marks it as visited; the traversal ends when the queue is empty. For example, if the failed operation node is number 8, then it sequentially visits its predecessor nodes numbered 7, 6, 5, etc., ensuring that all predecessor nodes are covered.

[0086] The process involves marking successful execution nodes as successfully executed nodes and creating a set of successfully executed operation nodes. The marking process is as follows: check the execution status flag field of each visited node; a successful status is indicated by a specific flag value. Nodes with successful status flags are added to the set of successfully executed operation nodes. The set data structure uses an array list for storage, with each element containing the operation node identifier field value, the source system identifier field value, and the operation type identifier field value. For example, if 10 preceding nodes are traversed, and 7 of them have successful status flags, then a set containing 7 elements is formed.

[0087] S3. Based on the business process topology diagram, traverse all source system interfaces corresponding to successfully executed operation nodes and extract the compensation capability identifiers of each interface. The specific implementation is as follows:

[0088] When retrieving the set of successfully executed operation nodes marked in the business process topology diagram, a structured data object is read from the data transmission channel output by the preceding steps. This data object contains a global transaction identifier field, a failed operation node identifier field, and a list of successfully executed operation nodes field. For example, if a data object with a global transaction identifier of "G20240514120300" is read, the list of successfully executed operation nodes contains multiple elements. Each element has an operation node identifier field value, a source system identifier field value, and an operation type identifier field value. The number of elements is determined based on the actual number of successful nodes.

[0089] For each successfully executed operation node in the set of operation nodes, a predefined interface metadata registry is queried to locate the corresponding source system interface. The query process is as follows: each operation node element in the set of operation nodes is processed sequentially; the source system identifier field value and operation type identifier field value of the current operation node are extracted; these two field values ​​are combined to form a query key; and an exact match query operation is performed in the storage system of the interface metadata registry. The interface metadata registry is stored in a table structure, which includes columns for source system identifier, operation type identifier, interface access address, interface protocol type, and compensation capability identifier. For example, when the source system identifier field value is "TAXATION" and the operation type identifier field value is "CALCULATION", the corresponding row record is located in the table.

[0090] The compensation capability identifier for each source system interface is extracted from the interface metadata registry. The extraction process is as follows: In the retrieved interface metadata record row, the cell value corresponding to the compensation capability identifier column is accessed. This cell stores a fixed-length string of data, with a fixed length of 3 characters. The first character of the string indicates the transaction rollback support capability, the middle character indicates the existence of an independent reverse operation interface, and the last character indicates the need for manual intervention. For example, when the tax calculation interface is retrieved, the compensation capability identifier is "R1A", where the first character "R" indicates support for transaction rollback operations, the middle character "1" indicates the existence of an independent reverse operation interface, and the last character "A" indicates that manual intervention is required.

[0091] The extracted compensation capability identifiers are stored in a compensation capability identifier set. The storage process is as follows: a new collection container object is created, which adopts a key-value pair mapping structure; the key is set to the operation node identifier string, and the value is set to the compensation capability identifier string; for each compensation capability identifier extracted from a source system interface, the corresponding key-value pair element is added to the container. For example, when the operation node identifier is "OP_TAX002" and its compensation capability identifier is "R1A", then a mapping relationship "OP_TAX002" to "R1A" is added. After all operation node elements have been processed, a complete compensation capability identifier set container is formed.

[0092] The set of compensation capability identifiers is stored in a common data format, as shown in the complete example below:

[0093] {

[0094] "global_transaction_id": "G20240514120300",

[0095] "compensation_capabilities": {

[0096] "OP_REG001": "T0B",

[0097] "OP_TAX002": "R1A",

[0098] "OP_BANK001": "S1C"

[0099] }

[0100] }

[0101] "T0B" indicates that the interface supports transaction compensation operations, has no independent reverse interface, and requires no manual intervention; "R1A" indicates that it supports transaction rollback operations, has an independent reverse interface, but requires manual intervention; and "S1C" indicates that a special compensation process is required, has an independent reverse interface, and requires manual intervention. This set is saved to the storage system through the data persistence service for use in subsequent compensation strategy construction steps.

[0102] The method for constructing the interface metadata registry is as follows: During the initial system configuration phase, interface description documents from each source system are collected; the interface function description text in the description documents is analyzed; specific keywords are identified in the function description text, including operation description words such as "rollback," "cancel," "compensation," and "manual review"; compensation capability characteristics are determined based on the keyword identification results; the compensation capability characteristics are converted into three-character codes; and finally, a registry record containing all business interfaces is formed. For example, when the interface description text contains the phrase "supports transaction rollback," the first character is set to "R"; when the description text contains "provides cancellation interface," the middle character is set to "1"; and when the description text contains "requires administrator approval," the last character is set to "A."

[0103] The encoding rules for the compensation capability identifier are detailed below: The first character indicates the type of compensation mechanism, with possible values ​​including "R" for supporting transaction rollback, "T" for supporting transaction compensation, and "S" for requiring a special compensation process; the middle character indicates the presence of a reverse interface, with possible values ​​including "0" for no independent reverse operation interface and "1" for the presence of an independent reverse operation interface; the last character indicates the need for manual intervention, with possible values ​​including "A" for requiring manual intervention, "B" for not requiring manual intervention, and "C" for requiring manual intervention under specific conditions. The value of each character is determined by analyzing the functional description in the interface documentation.

[0104] The data storage and transmission process includes integrity safeguards: when reading the set of operation nodes from the message channel, the digital signature of the data object is verified; when sending a query request to the interface metadata registry, a timeout threshold, such as 3000 milliseconds, is set; when storing the set of compensation capability identifiers, a data verification code is generated; when a query operation fails, the query operation is retried up to 3 times; when 3 consecutive queries fail, the error message is recorded and the current operation node is skipped. These measures ensure the reliability of data processing.

[0105] After the set of compensation capability identifiers is constructed, its integrity is checked through a data validation process: This includes verifying that the number of key-value pairs in the set matches the number of elements in the input operation node set; verifying that the length of each compensation capability identifier string is at least 3 characters; and verifying that the identifier characters are within the allowed value range. For example, when checking the identifier "R1A", it confirms that "R" belongs to {R,T,S}, "1" belongs to {0,1}, and "A" belongs to {A,B,C}. Once the validation is successful, the set is marked as ready.

[0106] S4. Construct a dynamic compensation strategy tree based on the compensation capability identifier, as detailed below:

[0107] When parsing the type of each compensation capability identifier in the compensation capability identifier set, key-value pair data is read from the compensation capability identifier set container generated in the previous step. For each key-value pair element, the compensation capability identifier string of the value field is extracted. This string is an encoded string of fixed length 3 characters. The string is split into three independent characters: the first character is parsed as the transaction rollback support identifier, the second character is parsed as the independent reverse operation interface identifier, and the third character is parsed as the manual intervention identifier. For example, in the compensation capability identifier "R1A", the first character "R" indicates support for transaction rollback operations, the second character "1" indicates the existence of an independent reverse operation interface, and the third character "A" indicates that manual intervention is required.

[0108] The corresponding compensation operation instruction unit is generated based on the type of the compensation capability identifier. The generation rules are as follows: When the first character is a specific character value, a rollback function call instruction unit is created. This instruction unit contains a transaction rollback function name field and a rollback parameter mapping table field. The rollback parameter mapping table field value is extracted from the business context data to obtain the set of input parameters for the failed operation. When the second character is a specific character value, a reverse operation interface sequence instruction unit is created. This instruction unit contains a target interface access address field, a request parameter template field, and a result processing script field. When the third character is a specific character value, a manual intervention alarm instruction unit is created. This instruction unit contains an alarm receiver identifier field, an alarm content template field, and a timeout threshold parameter field. For example, for the identifier "R1A", three types of instruction units are generated: the rollback function call instruction unit calls a function named "rollback_transaction", the reverse operation interface sequence instruction unit calls an interface with the address " / compensation / tax", and the manual intervention alarm instruction unit sets the timeout threshold parameter value to 300 seconds.

[0109] Based on the reverse connection relationship of successfully executed operation nodes in the business process topology diagram, the compensation operation instruction units are arranged into an initial linear sequence. The arrangement process is as follows: obtain the set of successfully executed operation nodes from the business process topology diagram; determine the original execution order of the operation nodes according to the directed edge connection relationship between the nodes in the topology diagram; use the complete reverse order of the original execution order as the basic arrangement order of the compensation instruction units; arrange the compensation operation instruction units corresponding to each operation node in sequence according to the basic arrangement order. For example, if the original execution order is node A → node B → node C, then the compensation sequence is arranged as the instruction corresponding to node C → the instruction corresponding to node B → the instruction corresponding to node A. If the same operation node generates multiple compensation operation instruction units, they are arranged in a fixed priority order of rollback function call instruction units, reverse operation interface sequence instruction units, and manual intervention alarm instruction units.

[0110] Based on the resource dependency rules between interface operations, the execution order of compensation operation instruction units is adjusted. The adjustment process is as follows: A predefined set of resource dependency rules is loaded; the real estate ownership object identifier field value involved in the compensation operation instruction unit is parsed; the rollback function call instruction unit is extracted from the rollback parameter mapping table field; and the reverse operation interface sequence instruction unit is extracted from the request parameter template field. According to the resource dependency rule set, resource conflict relationships between instruction units are detected; when two instruction units have resource dependencies, their execution order is adjusted so that the resource user executes before the resource provider. For example, if it is detected that the instruction unit of node B needs to read the real estate identifier X modified by node A, then the instruction unit of node A is adjusted to be executed after the instruction unit of node B.

[0111] A dynamic compensation strategy tree with a tree-like topology is constructed, using resource dependencies as connecting edges and compensation operation instruction units as node elements. The construction process is as follows: each compensation operation instruction unit is treated as a tree node element; resource dependencies between node elements are analyzed; when the output resource of node A's instruction unit is used as the input resource of node B's instruction unit, a directed connecting edge is created from node B to node A; when multiple dependencies exist between node elements, a multi-branch structure is formed; finally, a directed acyclic graph structure is generated, with instruction units as node elements and dependencies as connecting edges. For example, if node C's instruction unit depends on the output resources of nodes A and B, a tree structure is formed with C as the root node element and A and B as child nodes. This tree structure generates an executable sequence through topological sorting to ensure that resource dependency constraints are met. After the tree is constructed, loop detection is performed; when a circular dependency is detected, a manual intervention alarm instruction unit is automatically generated.

[0112] The method for obtaining resource dependency rules includes: parsing the input parameter list fields and output parameter list fields declared in the interface documents of each source system; extracting field items involving real estate ownership object identifiers from the parameter list fields, with field item naming following the real estate unit coding format; establishing read-write dependencies between interface operations based on the ownership change constraint entries in the real estate registration business rule base; and abstracting the read-write dependencies into resource dependency rule entries and storing them in the rule base. The specific implementation is as follows:

[0113] The API documentation parsing function is invoked, taking the source system identifier parameter as input and outputting parameter structure data. For example, in the tax system API documentation, the "target_property_id" field item in the input parameter list and the "new_ownership_status" field item in the output parameter list are extracted.

[0114] Identify string values ​​conforming to the real estate unit coding format in the parameter structure data. The coding format includes administrative division code segment, land category code segment, parcel number segment, and fixture number segment. For example, extract the complete identifier from the value "310115GB00012FD00345" in the "target_property_id" field.

[0115] Query the ownership change constraint entries in the real estate registration business rule base. For example, the constraint entry "Mortgage registration operation requires ownership status to be private" indicates that the mortgage interface operation depends on the ownership status change operation. Generate read-write dependencies based on the constraint entries: when the ownership status value in the output parameter of operation A is a constraint condition of the input parameter of operation B, establish a dependency connection from operation B to operation A;

[0116] Dependencies are abstracted into a triple rule structure: (source operation type identifier, target operation type identifier, dependent resource type identifier). For example, (ownership transfer operation, mortgage registration operation, ownership state value). The rules are stored in a graph-structured database, where nodes are operation type identifiers and edges are dependency identifiers.

[0117] The application of resource dependency rules includes a conflict resolution mechanism: when multiple rules conflict in order, they are sorted and processed according to their priority values. The priority values ​​are set based on the rule's source type, with core business rules for real estate registration having higher priority values ​​than ordinary business rules. For example, the priority value of an ownership status dependency rule is set to 5, and the priority value of a tax calculation dependency rule is set to 3. The priority value range is set from 1 to 5 and can be manually configured through the rule configuration interface.

[0118] The strategy tree generation process is configured with timeout threshold parameters and exception handling procedures: the maximum time for building a single tree is limited to 2000 milliseconds; when a timeout occurs or an unresolved dependency conflict is detected, the process switches to a fully manual intervention mode; each time the strategy tree is updated, a version identifier field value is generated, and a version mapping relationship is established with the set of compensation capability identifiers.

[0119] The parameter sources for compensation operation instruction units are subject to explicit constraints: the parameter mapping table field values ​​for rollback function call instruction units are copied from the input parameter set fields of the business context data; the request parameter template field values ​​for reverse operation interface sequence instruction units are generated based on the definition in the interface metadata registry; and the receiver identifier field values ​​for manual intervention alarm instruction units are read from the system configuration table. All parameters undergo data type validation during generation; for example, property identifiers must meet the 18-bit character length rule.

[0120] The execution order of the dynamic compensation strategy tree is determined by a topology sorting algorithm, which ensures that the current instruction is executed only after all dependencies are satisfied. After each instruction unit is executed, a status report is generated. The status report includes an execution time field and an execution result code field. A value of 0 in the execution result code field indicates success, while a non-zero value indicates failure. The status report is updated in real time to the status records of the strategy tree nodes.

[0121] S5. Parse the real estate ownership dependency chain in the business context data and check whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, reconstruct the compensation instruction sequence based on the constraint rules of the real estate status change graph. The specific implementation is as follows:

[0122] When extracting the set of property ownership object identifiers from business context data, a specific field node in the business context data storage area is accessed. This field node is marked as the "property_object_ids" field in the business context data and is stored as a string array data structure. The extraction process is as follows: read the business context data document, locate the "property_object_ids" field node, and obtain all string elements under this node to form a collection object.

[0123] The system queries the real estate register based on the set of real estate ownership object identifiers to obtain dependency relationship data between real estate ownership objects. The query process is as follows: a structured query request object is constructed, with the set of real estate ownership object identifiers as the request parameter; a batch query command is sent to the real estate register database system through the data access interface; the database system executes a join query operation and returns a set of dependency relationship data records. The dependency relationship data includes fields for ownership object identifiers, dependent object identifiers, and dependency type.

[0124] The dependency data is constructed into a chain of real estate ownership dependency relationships. The construction process is as follows: Initialize a directed graph data structure container; use each real estate ownership object identifier as a graph node element; based on the dependency data record set, create directed edges between the dependent object identifier and the depended-on object identifier; the direction of the edges is from the depended-on object to the dependent object; the attributes of the edges are set to the dependency type field values. For example, if object A depends on object B, then a directed edge is created from B to A. This ultimately forms a chain-like topology representing ownership dependencies.

[0125] The compensation operation instruction units in the dynamic compensation strategy tree are arranged into a compensation instruction sequence according to their execution order. The arrangement process is as follows: the dynamic compensation strategy tree is processed by a topological sorting algorithm; a linear execution sequence is generated based on the dependency connection edges between node elements; each element in the sequence corresponds to a compensation operation instruction unit; the sequence order ensures no dependency conflicts. For example, generating the sequence [instruction unit C, instruction unit B, instruction unit A] means that instruction unit C is executed first, then instruction unit B, and finally instruction unit A.

[0126] The system checks whether the operation type field value and operation object identifier field value of each instruction in the compensation instruction sequence violate the dependency constraints defined in the real estate ownership dependency chain. The detection process is as follows: traverse each instruction unit element in the compensation instruction sequence; extract the operation object identifier field value from the instruction unit element; query all dependency constraints for that object identifier in the real estate ownership dependency chain; and check whether the instruction operation type field value satisfies the dependency constraints. For example, when the instruction unit operation type field value is "release mortgage," check whether the dependency chain contains the constraint "the seizure must be released first."

[0127] When a violation of dependency constraints is detected, the missing dependency operation instruction unit is inserted into the compensation instruction sequence according to the precondition rule entries for state transitions in the real estate status change map. The insertion process is as follows: query the precondition rule entries for the transition from the current state value to the target state value from the real estate status change map; generate the corresponding compensation operation instruction unit based on the rule entries; and insert the newly generated instruction unit element before the instruction unit element that violates the constraint. For example, if a mortgage release instruction is found to violate the constraint "the seizure must be released first," then a seizure release instruction unit is inserted before the mortgage release instruction in the sequence.

[0128] Remove operational instruction units from the compensation instruction sequence that cause dependency breaks. The removal process involves: analyzing the changes in ownership status after the execution of the compensation instruction sequence; detecting any potential breakage risks in the real estate ownership dependency chain; and removing the instruction unit element from the sequence when its execution would prevent the dependency from being satisfied. For example, removing a registration revocation instruction unit that would invalidate the ownership status.

[0129] Generate the reconstructed compensation instruction sequence. The generation process is as follows: after applying all insertion and removal operations, a new sequence object is formed; the new sequence object undergoes secondary verification of dependency constraints; the sequence format is maintained as an array structure of compensation operation instruction units; a sequence version identifier field and a generation timestamp field are added. For example, the final sequence is [Instruction Unit D, Instruction Unit C, Instruction Unit B], where instruction unit D is the newly inserted dependent instruction unit.

[0130] The method for constructing a real estate status change graph is as follows: Collect historical real estate registration data records; extract the original status field value, new status field value, and change operation type field value from the status change records; establish status change rule entries; and form a graph structure of status nodes and status transition connection edges. Specific implementation includes: defining ownership status node types, including private, joint ownership, and state-owned status; defining mortgage status node types, including mortgaged and unmortgaged status; defining seizure status node types, including seized and unseized status; analyzing the precondition field values ​​in the change records, for example, the precondition for changing from "mortgaged status" to "unmortgaged status" is "no seizure status"; storing rules as a triple structure: (original status value, new status value, precondition set field); creating status nodes; adding status transition connection edges according to the transition rules; and recording the precondition set field values ​​as connection edge attributes.

[0131] The dependency constraint detection algorithm is implemented as follows: Initialize the detection tag table data structure; traverse the instruction sequence objects; for each instruction unit element, check the positional relationship of its operand identifier in the dependency chain; verify that the execution of the instruction will not destroy downstream dependencies. For example, the release of a mortgage instruction must ensure that it does not affect the validity of the ownership status.

[0132] Anomaly handling mechanism during the refactoring process: When the number of inserted instruction units exceeds the threshold, a manual review process is triggered. The threshold is set to twice the length of the original sequence. When the sequence refactoring processing time exceeds the set threshold, a simplified refactoring mode is enabled. The threshold is set to 1000 milliseconds. Each refactoring operation generates an operation log to record the refactoring reason field value and the change point field value.

[0133] The verification method for the reconstructed sequence is as follows: Simulate the execution of the compensation instruction sequence; check the ownership status field values ​​at key nodes; compare the integrity status of the dependency chain before and after execution; generate a verification report object containing either a pass flag field or a failure flag field. Once verification is successful, the sequence is marked as executable.

[0134] The storage structure of the compensation instruction sequence adopts a transactional data structure, including a global transaction identifier field, a sequence version number field, and an instruction unit array field. The sequence version number field value is incremented after each reconstruction to ensure version tracking capability. The increment rule for the sequence version number field value is to add 1 to the original version number integer value, with an initial value of 1.

[0135] The maintenance mechanism for the real estate ownership dependency chain includes: automatically updating dependency data when a new real estate registration transaction is detected; setting a dependency chain version number field and establishing a correlation with the compensation instruction sequence version number field; and periodically verifying the integrity of the dependency chain, with a verification cycle set to 24 hours. The verification process includes checking for the existence of orphaned nodes and circular dependencies.

[0136] The operation type field values ​​of the compensation operation instruction unit are categorized into: ownership status change operation type, mortgage status change operation type, and seizure status change operation type. Each operation type field value corresponds to a specific status transition rule, which is stored in the real estate status change graph for querying. For example, the ownership status change operation type corresponds to the transition rule of the ownership status node.

[0137] The technical effects of reconstructing the compensation instruction sequence include: ensuring that the transaction compensation process for real estate registration complies with the rules for ownership change; avoiding inconsistencies in ownership status caused by compensation operations; and improving the reliability and compliance of compensation operations. These effects are achieved through dependency constraint detection and sequence reconstruction processing.

[0138] After completing the construction of the dynamic compensation strategy tree, the intelligent reconstruction of the compensation sequence is achieved through deep coupling of real estate registration rules. Specifically, although the compensation instruction sequence generated by S4 optimizes the resource dependency order, it does not cover the ownership constraints unique to real estate (such as the requirement that the mortgage status change must be based on the release of the seizure status). S5 introduces the real estate ownership dependency chain and status change graph: First, the dependency relationship in the register (such as "release of mortgage requires release of seizure first") is transformed into a computable topological chain; second, the risk of the instruction sequence damaging this topological chain is detected in real time (such as executing the release of mortgage instruction first will lead to a conflict in ownership status); finally, the sequence is dynamically reconstructed based on the status graph rules (such as the "release of mortgage" operation must meet the "no seizure" status) - automatically inserting missing operations (such as adding the release of seizure instruction before the release of mortgage) or removing conflicting operations (such as deleting the registration revocation that will cause the ownership to be invalid), deeply integrating the general transaction compensation mechanism with real estate business rules to break through the compliance bottleneck of the traditional compensation process in the property rights transaction scenario.

[0139] S6. Execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated. The specific implementation is as follows:

[0140] When obtaining the reconstructed compensation instruction sequence, a sequence data object is read from the compensation instruction sequence storage area generated in the previous step. This sequence data object contains a global transaction identifier field, a sequence version number field, and a compensation operation instruction unit array field. The reading process is as follows: The sequence record set is queried based on the global transaction identifier parameter, and the record with the largest sequence version number field value is selected as the current sequence data object. For example, if the global transaction identifier "G20240514120300" corresponds to a sequence version number field value of 3, then the sequence data object for that version is obtained.

[0141] Following the reverse order of successfully operated nodes in the business process topology diagram, each compensation operation instruction unit in the reconstructed compensation instruction sequence is executed sequentially. The execution process is as follows: the execution counter field value is initialized to 0; the compensation operation instruction units are traversed starting from index 0 in the sequence array index order; for each compensation operation instruction unit, the execution method is selected according to its instruction type field value: the rollback function call instruction unit calls the function execution service, the reverse operation interface sequence instruction unit calls the interface call service, and the manual intervention alarm instruction unit calls the alarm distribution service. For example, when executing the reverse operation interface sequence instruction unit at index 0, a Hypertext Transfer Protocol (HTTP) POST request is sent to the target interface access address field value.

[0142] After each compensation operation instruction unit is executed, the status query function of the corresponding source system interface is invoked. The invocation process is as follows: extract the source system identifier field value and operation type identifier field value from the compensation operation instruction unit; combine them to generate the status query interface access address string; construct a query request object, send it to the target system, and receive the response data object. For example, for the calculation operation interface of the tax system, the " / status / tax" query interface is called to obtain status data.

[0143] Retrieve the current ownership status value of the operation node corresponding to the compensation operation instruction unit. The retrieval process is as follows: parse the status query response data object, locate the ownership status field node; extract the status value string under the field node. Key status fields include: ownership status field value, mortgage status field value, and seizure status field value. For example, extract the value "private" from the "ownership_status" field in the response data object.

[0144] The current ownership status value is compared with the initial ownership status value in the business context data. The comparison process is as follows: read the initial ownership status snapshot document object from the business context data storage area; locate the initial status field value corresponding to the same operation node identifier and ownership object identifier; and perform a string exact match comparison operation. For example, the current ownership status field value "joint ownership" does not match the initial field value "private ownership".

[0145] If the current ownership status value is inconsistent with the initial ownership status value, the corresponding compensation operation instruction unit will be re-executed until the status is consistent or the preset retry threshold is reached. The retry process is as follows: the retry counter field value is initialized to 0; the compensation operation instruction unit is repeatedly executed; after each execution, the status query function is called again to obtain the current ownership status value and perform a comparison operation; the retry process is terminated when the retry counter field value reaches the preset retry threshold. The preset retry threshold is a configurable parameter, with a default value of 3 times.

[0146] When the preset retry count threshold is reached and the status remains inconsistent, a manual intervention alarm instruction unit for the corresponding operation node is generated. The generation process is as follows: create a new manual intervention alarm instruction unit object; set the values ​​for the operation node identifier field, the ownership object identifier field, and the abnormal status description field; add the newly generated manual intervention alarm instruction unit to the pending queue set. For example, the generated alarm instruction unit may include the description field value "Node OP_TAX002 ownership status recovery failed".

[0147] The implementation details of the status query function include: setting the query timeout threshold parameter to 5000 milliseconds; automatically retrying the query operation when it times out, with a maximum of 2 retries; and including a digital signature field in the query request object for authentication. The response data object uses JavaScript object notation and includes a timestamp field and a status code field, with a status code value of 200 indicating a successful query.

[0148] The accuracy control mechanism for ownership status comparison is as follows: For numerical status fields, an allowable error threshold parameter of 0.01 is set; for string-type status fields, a full match operation is performed; the comparison results record the difference details field value. The allowable error threshold parameter is set through the system configuration interface and can be adjusted from 0 to 1. For example, when comparing tax amount field values, if the difference of 0.02 between the current value 10.02 and the initial value 10.00 is greater than the threshold of 0.01, then an inconsistency is determined.

[0149] The distribution process for manually intervened alarm commands is as follows: The list of alarm receiver identifier field values ​​is read from the manually intervened alarm command unit; the distribution channel type is selected based on the receiver identifier type; the SMS channel uses a template engine to populate the alarm content template field values; and the system message channel calls the message push interface. The alarm content template includes timestamp field values, node identifier field values, and status difference field values.

[0150] Monitoring mechanism for the compensation execution process: Establish an execution status tracking table data structure; update the status record field value after each compensation operation instruction unit is executed; the status record field value includes "Executing", "Success", "Failure", "Retrying" status values, etc.; global transaction identifier is associated with the execution status record field values ​​of all compensation operation instruction units.

[0151] Exception handling boundary condition coverage: When the number of consecutive failure compensation operation instruction units reaches a threshold number, the entire sequence execution process is paused, and the threshold number is set to 5; when the total execution time exceeds the timeout threshold parameter value, the process is forcibly terminated, and the timeout threshold parameter value is set to 300 seconds; all exception events generate error code field values ​​and error description field values ​​and are recorded in the audit log document.

[0152] Compensation execution result verification report generation: After all compensation operation instruction units are executed, an ownership status verification report document object is generated; the report document contains the initial status field value, current status field value, and comparison result field value of each operation node; the overall verification result field value is either "fully recovered" or "partially recovered" status value; in the case of partial recovery status, the set of unrecovered node identifier field values ​​is listed.

[0153] The method for obtaining the initial ownership status value is as follows: At the start of the business process, an initial ownership status snapshot document is created; the initial status field values ​​of the operation nodes are obtained by calling the status query interfaces of each source system; the status field values ​​are organized and stored according to the operation node identifier and ownership object identifier. The snapshot document version is bound to the global transaction identifier for storage.

[0154] The preset retry threshold is set based on the business criticality level: 3 times for ordinary business needs and 5 times for critical business needs. The threshold parameters are stored in the system configuration table and can be modified through the configuration management interface. The retry interval uses an exponential backoff algorithm, with an initial interval of 500 milliseconds and a maximum interval of 8000 milliseconds.

[0155] Verification of the execution order of compensation operation instruction units: Before execution, verify whether the sequence order conforms to the reverse order relationship of the business process topology diagram; confirm the validity of the reverse order by comparing the position index of the operation node in the topology diagram; terminate execution and generate a sequence error alarm when an abnormal order is detected. The position index is assigned incrementally starting from the starting node of the business process.

[0156] Example 2: Figure 2 A schematic diagram of a real estate data sharing system based on a multi-source interface is provided according to the present invention. The real estate data sharing system based on a multi-source interface includes:

[0157] The transaction monitoring module is used to monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, it captures the exception transaction identifier and business context data of the failed operation.

[0158] The node marking module is used to query the business process topology diagram based on the abnormal transaction identifier and mark all operation nodes that have been successfully executed before the corresponding node.

[0159] The identifier extraction module is used to traverse all source system interfaces corresponding to successfully executed operation nodes based on the business process topology diagram and extract the compensation capability identifier of each interface.

[0160] The strategy construction module is used to build a dynamic compensation strategy tree based on the compensation capability identifier;

[0161] The sequence reconstruction module is used to parse the real estate ownership dependency chain in the business context data and detect whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, it reconstructs the compensation instruction sequence based on the constraint rules of the real estate status change map.

[0162] The state recovery module is used to execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

[0163] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0164] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0165] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0166] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0167] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0168] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0169] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0170] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0171] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0172] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for sharing real estate data based on multi-source interfaces, characterized in that, include: S1. Monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, capture the exception transaction identifier and business context data of the failed operation. S2. Query the business process topology diagram based on the abnormal transaction identifier, and mark all operation nodes that have been successfully executed before the corresponding node; S3. Based on the business process topology diagram, traverse all source system interfaces corresponding to successfully executed operation nodes and extract the compensation capability identifiers of each interface. S4. Construct a dynamic compensation strategy tree based on the compensation capability identifier, including: The type of each compensation capability identifier in the compensation capability identifier set is analyzed. The types include transaction rollback support identifier, independent reverse operation interface identifier, and manual intervention identifier. Generate the corresponding compensation operation instruction unit based on the type of the compensation capability identifier; According to the reverse connection relationship of the operation nodes that have been successfully executed in the business process topology diagram, the compensation operation instruction units are arranged into an initial linear sequence; Based on the resource dependency rules between interface operations, adjust the execution order of compensation operation instruction units; A dynamic compensation strategy tree with a tree-like topology is constructed using resource dependencies as edges and compensation operation instruction units as nodes. S5. Parse the real estate ownership dependency chain in the business context data, and check whether the instruction sequence in the dynamic compensation strategy tree disrupts the topological structure of the real estate ownership dependency chain; if so, reconstruct the compensation instruction sequence based on the constraint rules of the real estate status change graph, including: Extract the set of real estate ownership object identifiers from the business context data; Query the real estate register based on the set of real estate ownership object identifiers to obtain dependency relationship data between real estate ownership objects; Construct a real estate ownership dependency chain from the dependency data; The compensation operation instruction units in the dynamic compensation strategy tree are arranged into a compensation instruction sequence according to the execution order; Detect whether the operation type and operation object of each instruction in the compensation instruction sequence violate the dependency constraints defined in the real estate ownership dependency chain; When a violation of dependency constraints is detected, the missing dependency operation instruction unit is inserted into the compensation instruction sequence according to the precondition rules for state transition in the real estate status change map. Remove the operation instruction unit from the compensation instruction sequence that causes the dependency breakage; Generate the reconstructed compensation instruction sequence; S6. Execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

2. The method for sharing real estate data based on multi-source interfaces according to claim 1, characterized in that, Monitor the execution status of each interface operation in the cross-system business process. When an interface operation fails, capture the exception transaction identifier and business context data of the failed operation, including: When an interface operation fails, the global transaction identifier is combined with the transaction identifier of the failed interface operation to generate an exception transaction identifier. Capture business context data, which includes the set of input parameters for failed interface operations, the set of associated real estate ownership object identifiers, and a snapshot of the state of each source system at the time of the interface call; The initial ownership status value corresponding to the set of real estate ownership object identifiers is read from the real estate registration database, and the initial ownership status value is used as the base value of the business context data.

3. The method for sharing real estate data based on a multi-source interface according to claim 2, characterized in that, Based on the abnormal transaction identifier, query the business process topology diagram and mark all operation nodes that have been successfully executed before the corresponding node, including: Parse the global transaction identifier from the abnormal transaction identifier; Query the pre-stored business process topology diagram based on the global transaction identifier; Locate the failed operation node associated with the abnormal transaction identifier in the business process topology diagram; Traverse all operation nodes in the business process topology diagram that are preceding the failed operation node; Mark the successfully executed operation nodes among the traversed operation nodes as successfully executed operation nodes and form a set of successfully executed operation nodes.

4. The method for sharing real estate data based on a multi-source interface according to claim 3, characterized in that, Based on the business process topology diagram, traverse all source system interfaces corresponding to successfully executed operation nodes, and extract the compensation capability identifiers of each interface, including: Obtain the set of successfully executed operation nodes marked in the business process topology diagram; For each operation node in the set of successfully executed operation nodes, query the predefined interface metadata registry to locate the corresponding source system interface; Extract the compensation capability identifier for each source system interface from the interface metadata registry; The extracted compensation capability identifiers are stored in the compensation capability identifier set.

5. A method for sharing real estate data based on a multi-source interface according to claim 1, characterized in that, The compensation operation instruction unit includes a rollback function call instruction unit, a reverse operation interface sequence instruction unit, or a manual intervention alarm instruction unit.

6. The method for sharing real estate data based on a multi-source interface according to claim 1, characterized in that, The resource dependency rules between API operations are obtained in the following ways: Parse the input and output parameters declared in the interface documents of each source system; Extract the real estate ownership object identifiers involved in the input and output parameters; Based on the ownership change constraints in the real estate registration business rule base, establish read / write dependencies between different interface operations on the same ownership object; Abstract read-write dependencies into resource dependency rules.

7. A method for sharing real estate data based on a multi-source interface according to claim 4, characterized in that, Execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to its initial value before the business was initiated, including: Obtain the reconstructed compensation instruction sequence; According to the reverse order of the successfully operated nodes in the business process topology diagram, each compensation operation instruction unit in the reconstructed compensation instruction sequence is executed sequentially. After each compensation operation instruction unit is executed, the status query function of the source system interface corresponding to the corresponding compensation operation instruction unit is called. Obtain the current ownership status value of the operation node corresponding to the compensation operation instruction unit; Compare the current ownership status value with the initial ownership status value in the business context data; If the current ownership status value is inconsistent with the initial ownership status value, the corresponding compensation operation instruction unit will be re-executed until the status is consistent or the preset retry number threshold is reached. When the preset retry count threshold is reached and the status is still inconsistent, a manual intervention alarm instruction unit is generated for the corresponding operation node.

8. A real estate data sharing system based on a multi-source interface, used to implement the real estate data sharing method based on a multi-source interface as described in any one of claims 1-7, characterized in that, include: The transaction monitoring module is used to monitor the execution status of each interface operation in the cross-system business process. When the interface operation fails, it captures the exception transaction identifier and business context data of the failed operation. The node marking module is used to query the business process topology diagram based on the abnormal transaction identifier and mark all operation nodes that have been successfully executed before the corresponding node. The identifier extraction module is used to traverse all source system interfaces corresponding to successfully executed operation nodes based on the business process topology diagram and extract the compensation capability identifier of each interface. The strategy construction module is used to build a dynamic compensation strategy tree based on the compensation capability identifier; The sequence reconstruction module is used to parse the real estate ownership dependency chain in the business context data and detect whether the instruction sequence in the dynamic compensation strategy tree destroys the topological structure of the real estate ownership dependency chain; if so, it reconstructs the compensation instruction sequence based on the constraint rules of the real estate status change map. The state recovery module is used to execute the reconstructed compensation instruction sequence in reverse order of the business process topology diagram until the state of all successfully operated nodes is restored to the initial value before the business was initiated.

Images