Sap closed-loop operation and maintenance method and system based on change influence graph

Abstract

The application belongs to the technical field of enterprise resource planning system operation and maintenance, and discloses an SAP closed-loop operation and maintenance method and system based on a change influence graph. The method analyzes an SAP change package and constructs a change influence graph containing nodes, directed edges, state fingerprints and evidence identifiers; generates an influence path after verifying the directed edges and sets a verification point; divides a release batch according to shared verification points and activated dependencies, replays transactions by using desensitized input; locates deviated nodes according to a calling track, determines an abnormal path, an initial rollback set and a target rollback set and executes rollback; and adds, suspends or resumes directed edges according to cross-session calling records. The application can improve the accuracy of change influence analysis, abnormal positioning and rollback processing.

Description

Technical Field

[0001] This invention relates to the field of enterprise resource planning system operation and maintenance technology, specifically to an SAP closed-loop operation and maintenance method and system based on change impact mapping. Background Technology

[0002] SAP systems typically handle enterprise operations such as finance, procurement, sales, production, and inventory. As business rules, custom programs, data structures, interface configurations, and back-end operations are continuously adjusted, changes in the development system need to be imported into the test or production system via SAP change packages. A single change object may affect multiple technical objects and business processes through object references, program calls, data read / write operations, interface transmissions, and job triggers. Therefore, it is usually necessary to determine the scope of impact and arrange regression testing before release.

[0003] Chinese invention patent CN112380130B discloses an application testing method and apparatus based on call dependencies. It identifies modified nodes by comparing the code of the application under test with historical application code, determines call dependency nodes using call traces, and determines the testing focus and scope based on call frequency. While this approach can narrow the testing scope of general application software based on code changes and call relationships, it primarily focuses on code methods, call dependencies, and testing scope. It does not provide unified processing for SAP repository objects, client-related configuration records, interface nodes, background job nodes, and business process step nodes, nor does it determine whether historical dependencies are still applicable to the current change based on object status and client environment.

[0004] Existing SAP operations tools can also perform change impact analysis. For example, the Business Process ChangeAnalyzer can analyze business processes affected by changes and support test coverage checks; the Scope and EffortAnalyzer can analyze the impact of software changes on custom code, modified objects, and business processes, and estimate rework and regression testing workload. These technologies are primarily used to identify affected objects or determine the test scope. However, they lack unified constraints on object versions, client identifiers, and evidence status at the time the impact relationship is formed. Historical call relationships may still participate in impact propagation after changes in object versions or client configurations, leading to an expanded test scope or omission of critical paths.

[0005] Furthermore, existing solutions typically determine release success based on final test results, making it difficult to establish continuous status verification at points such as initial data writes, execution branches, and multi-path convergence. When transaction replays result in out-of-path calls, failure to reach expected verification points, or abnormal verification point states, it's also difficult to accurately pinpoint the initial deviation. After verification failure, reverting the entire SAP change package simultaneously rolls back objects that didn't experience anomalies. However, manually selecting partial object rollbacks can disrupt object activation dependencies or version compatibility relationships between program objects, data structures, core data service views, and configuration records, preventing objects from activating or running together. On the other hand, directly including occasional calls occurring during a single transaction execution in the impact relationship can interfere with subsequent impact analysis due to these occasional execution trajectories. Therefore, a closed-loop SAP operation and maintenance solution is needed that can verify the validity of impact relationships, limit abnormal paths based on actual execution trajectories, narrow the rollback scope while maintaining compatibility of related objects, and continuously update the change impact graph based on cross-session execution evidence. Summary of the Invention

[0006] The purpose of this invention is to provide an SAP closed-loop operation and maintenance method, system and electronic equipment based on change impact map, so as to improve the accuracy of SAP change impact path identification and deviation node location, and reduce the rollback range while ensuring that related objects can be activated and run together.

[0007] To achieve the above-mentioned technical objectives, the present invention provides the following technical solution.

[0008] In a first aspect, the present invention provides an SAP closed-loop operation and maintenance method based on a change impact map, comprising:

[0009] S1. Obtain SAP change packages and identify change units by object type, object key, and versions before and after the change; generate nodes and directed edges between nodes based on object references, runtime calls, data access, interface messages, and background job records to form a change impact graph, and bind source, target node status fingerprint, client identifier, and evidence identifier to the directed edges.

[0010] S2. Verify the state fingerprint, client identifier, and evidence record of the directed edges, and form an impact path only along the directed edges that have passed verification; set verification points at the first data writing node, branch node, and merge node;

[0011] S3. Group shared verification points or change units with direct activation dependencies into the same batch and import them into the target system sequentially; use desensitized input replay transactions that maintain field associations, and associate call trajectories and verification point status by session;

[0012] S4. Compare the call trajectory with the affected path, and take the source node of the call outside the path, the verification point that has not been reached or has an inconsistent status as the candidate deviation node, and take the first one as the deviation node; take the path from the change unit in this batch to the deviation node as the abnormal path, select the initial rollback set that covers the abnormal path and has the fewest units, expand it into the target rollback set according to the activation dependency and version compatibility relationship, and then rollback.

[0013] S5. When the node state fingerprint remains unchanged and the cumulative cross-session edge addition threshold is reached, a new directed edge is added for the same unrecorded call relationship. When the source node is visited and the edge is not visited consecutively and the dormancy threshold is reached, the edge is dormant and will be restored when the call relationship meets the new edge addition condition again.

[0014] Specifically, in step S1:

[0015] The change unit is jointly identified by object type, object key, source system identifier, target system identifier, client identifier, version before change, and version after change. The client identifier is the SAP client identifier in the target SAP system.

[0016] The change unit corresponds to an SAP warehouse object or client-related configuration record;

[0017] The SAP warehouse objects include one or more of the following: ABAP programs, classes, function modules, data dictionary objects, core data service views, and enhanced implementations.

[0018] The client-related configuration records are the configuration records in the configuration table associated with the target SAP client.

[0019] Specifically, in steps S1 and S2:

[0020] The nodes include change unit nodes, technical object nodes, data object nodes, interface nodes, background operation nodes, and business process step nodes;

[0021] The directed edges include object reference edges, program call edges, data read / write edges, interface transmission edges, job triggering edges, and business process mapping edges;

[0022] The status fingerprints of change unit nodes, technical object nodes, and data object nodes are generated by the content and version identifier of the corresponding object or data structure. The status fingerprints of interface nodes, background job nodes, and business process step nodes are generated by the interface configuration, job definition, or business mapping content and the corresponding version identifier, respectively.

[0023] The evidence identifier points to the object reference record, runtime call record, data access record, interface message record, or background job record that generated the corresponding directed edge;

[0024] When the source node state fingerprint and target node state fingerprint of a directed edge are consistent with the current state fingerprint of the corresponding node in the target system, the client identifier is consistent with the target SAP client, the evidence record has not been deleted, the record source system matches the system to which the nodes at both ends of the directed edge belong and is within the preset validity period, the directed edge is deemed to have passed verification.

[0025] Specifically, in step S2:

[0026] The first data writing node is the source node of the first data writing edge encountered along the direction of the influence path propagation, and the target node of the first data writing edge is the data object node to be verified.

[0027] The branch node is a node with at least two outgoing edges participating in the propagation of influence, and the merging node is a node with at least two incoming edges participating in the propagation of influence.

[0028] If no node of the corresponding type exists in the affected path, no verification point of that type is set.

[0029] When the same node meets two or more verification point setting conditions at the same time, set a verification point on the node and merge the verification content corresponding to each setting condition.

[0030] The expected state of the verification point is determined based on the business transactions successfully executed before the change. The snapshot of the verification point before the change includes one or more of the following: active object version, configuration record, data structure version, and interface configuration.

[0031] Specifically, in step S3:

[0032] Change units that share the same verification point or have direct object activation dependencies in their corresponding impact paths are grouped into the same release batch, and the import order of each release batch is determined according to the direction of object activation dependencies.

[0033] The direct object activation dependency is that the activation of an object corresponding to a change unit requires the use of the active version or runtime object of another change unit corresponding to the object.

[0034] Import each release batch into the verification client or pre-defined application server group of the target SAP system;

[0035] The de-identified input is obtained by replacing the personal identification field and sensitive business fields, while retaining the primary key and foreign key relationships, business document reference relationships, organizational structure mapping relationships, and SAP client fields;

[0036] The session identifier is used to associate program call records, data read / write records, interface message records, background job records, and verification point status generated during the same transaction replay.

[0037] Specifically, in step S4:

[0038] Based on the call time, call order, and parent call identifier, the call trace corresponding to the same session identifier is mapped to the actual execution path;

[0039] When the relationship between adjacent nodes in the actual execution path is not included in the corresponding affected path, the source node that initiates the external call to that path will be identified as a candidate deviation node.

[0040] When a transaction replay is completed, if no status record is generated at the verification point in the affected path, the verification point is identified as a candidate deviation node; when the actual status generated by the verification point is inconsistent with the expected status, the verification point is identified as a candidate deviation node.

[0041] According to the order of nodes that propagate downstream from the corresponding impact unit, the first candidate deviation node is determined as the deviation node.

[0042] Extract the change units located on each abnormal path in the current release batch to form a candidate change unit set. Select change units from the candidate change unit set so that each abnormal path contains at least one selected change unit. Determine the combination with the fewest change units as the initial rollback set.

[0043] When there are multiple combinations with the same number of change units, the combination with the fewest associated business process steps is determined as the initial rollback set.

[0044] More specifically, in step S4, the rollback after expanding the target rollback set according to activation dependencies and version compatibility relationships includes:

[0045] The initial rollback set is determined as the current expansion set;

[0046] Check the object activation dependencies and version compatibility relationships between change units in the current extended set and change units within the current release batch and outside the current extended set;

[0047] When a change unit in the current extended collection is restored to the version before the change, it may cause the referenced object to be missing, the data type or field length to be mismatched, the core data service view output fields to be incompatible, the enhancement implementation to be unable to be activated, the interface parameters to be incompatible, or the object or configuration key referenced by the configuration record to be missing. In such cases, the associated change unit that has an object activation dependency or version compatibility relationship with the change unit that causes the corresponding state will be added to the current extended collection.

[0048] Repeat the check and add operation until the change units outside the current extended set can be activated and run together with the previous versions of each change unit in the current extended set, and determine the resulting current extended set as the target rollback set;

[0049] The SAP warehouse objects in the target rollback set can be restored by rolling back the transport request, or the client-related configuration records in the target rollback set can be restored based on the snapshot before the change, and the verification points associated with the target rollback set can be re-executed.

[0050] Specifically, in step S5:

[0051] The unrecorded call relationship refers to a call relationship that exists in the call trajectory but does not have a corresponding directed edge in the change impact graph;

[0052] When the source node, target node, call direction, client identifier, source node status fingerprint, and target node status fingerprint are all the same, they are determined to be the same call relationship;

[0053] The cross-session accumulation refers to the detection and cumulative counting of the same call relationship in the transaction replays corresponding to at least two different session identifiers;

[0054] When the source node state fingerprint or the target node state fingerprint changes, the corresponding unrecorded call relationships are recounted.

[0055] When a source node is visited in multiple consecutive transaction replays, but the corresponding directed edge is not visited, and the number of consecutive visits reaches the sleep threshold, the directed edge is marked as a sleep edge that does not participate in the propagation of influence.

[0056] When the call relationship corresponding to the dormant edge reaches the threshold for adding new edges again, and the source node state fingerprint, target node state fingerprint, and client identifier are consistent with the current state fingerprint of the target system and the target SAP client, respectively, the dormant edge will be restored as a directed edge participating in the influence propagation.

[0057] Secondly, the present invention also provides an SAP closed-loop operation and maintenance system based on a change impact map, for implementing the SAP closed-loop operation and maintenance method described in the first aspect, comprising:

[0058] The Change Analysis and Graph Construction module is used to parse SAP change packages, identify change units, generate nodes and directed edges between nodes, construct a change impact graph, and bind source node state fingerprints, target node state fingerprints, client identifiers, and evidence identifiers to the directed edges.

[0059] The influence path and verification point generation module is used to verify directed edges, form influence paths, and set verification points in the influence paths;

[0060] The release verification module is used to divide release batches, import change units, replay transactions, and collect call trajectories and verification point status.

[0061] The deviation positioning and rollback module is used to determine deviation nodes and abnormal paths, generate an initial rollback set and a target rollback set, and execute the rollback.

[0062] The graph update module is used to add directed edges, set dormant edges, and restore dormant edges.

[0063] Thirdly, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the processor executes the computer program, it implements the SAP closed-loop operation and maintenance method described in the first aspect.

[0064] This invention generates nodes and directed edges between nodes based on object reference records, runtime call records, data access records, interface message records, and background job records. It verifies the applicability of directed edges to the target system using source node state fingerprints, target node state fingerprints, client identifiers, and evidence records, thereby reducing interference from expired relationships or client mismatches on impact propagation. Verification points are set at the first data write node, branch node, and merge node of the impact path. Session identifiers are used to associate the call trajectory generated by transaction replay with the verification point status, enabling the identification of deviation nodes and limiting abnormal paths according to the path order. By first determining an initial rollback set that covers all abnormal paths and has the fewest change units, and then expanding the target rollback set according to object activation dependencies and version compatibility relationships, it can reduce the reversal of irrelevant changes while avoiding object reference loss, data type mismatch, or object inactivation failure caused by partial rollbacks. Simultaneously, directed edges are added based on cross-session call records under the condition that the state fingerprint remains unchanged, and continuous untraveled directed edges are put into hibernation and recovery processing, allowing the change impact graph to be continuously updated based on stable operational evidence. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of the structure of an SAP closed-loop operation and maintenance system based on change impact maps.

[0066] Figure 2 This is a flowchart illustrating an SAP closed-loop operation and maintenance method based on change impact mapping.

[0067] Figure 3 This is a schematic diagram illustrating the relationship between the change impact map, the impact path, and the verification points. Detailed Implementation

[0068] The technical solution of this application will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are intended to enable those skilled in the art to implement this application and are not intended to limit the scope of protection of this application. Without changing the processing relationship between each step, the system deployment location, data storage format, call record collection method, and specific object type can be adjusted according to the actual environment of the target SAP system.

[0069] I. Terminology Explanation The SAP system referred to in this invention is an enterprise information processing system that deploys SAP enterprise application software and includes an application server, database, SAP client, and interface runtime environment; the SAP system can be a locally deployed system, a cloud-deployed system, or a hybrid deployment system. In one embodiment, the SAP system is an SAP enterprise application system that supports ABAP program execution, warehouse object management, client configuration, and change transmission.

[0070] In this embodiment, an SAP change package refers to a set of changes to be imported from a source SAP system to a target SAP system. The SAP change package can be formed from a single transmission request or from multiple transmission requests with the same release purpose. An SAP change package may include SAP repository objects, client-related configuration records, or a combination of both.

[0071] SAP warehouse objects can include one or more of the following: ABAP programs, classes, function modules, data dictionary objects, core data service views, and enhanced implementations. Client-related configuration records refer to the records in the configuration table associated with a specific SAP client.

[0072] A change unit is an object unit identified from an SAP change package and used for impact analysis, release verification, and rollback processing. A change unit is identified by object type, object key, source system identifier, target system identifier, client identifier, pre-change version, and post-change version.

[0073] An object key is an identifier that can determine the identity of an object in the corresponding SAP system. An object key can be a program name, class name, function module name, data dictionary object name, core data service view name, enhancement implementation name, or a combination key consisting of a configuration table name and a configuration record key.

[0074] This implementation uses the format "business function name + object type" to describe the specific objects in the embodiments. For example, "pricing calculation object" represents a program object used to perform sales order pricing calculation, and "credit check function module" represents a function module used to perform credit checks. In a real system, object identifiers that conform to the enterprise naming rules can be assigned to the above objects, but this implementation is not limited to specific object identifiers.

[0075] The change impact graph is a data structure consisting of nodes and directed edges between them. Nodes include change unit nodes, technical object nodes, data object nodes, interface nodes, background operation nodes, and business process step nodes.

[0076] Change unit nodes represent change objects in SAP change packages; technical object nodes represent programs, classes, function modules, data dictionary objects, core data service views, or enhanced implementations; data object nodes represent business tables, configuration tables, or data structures; interface nodes represent remote function call interfaces, service interfaces, or message interfaces; background job nodes represent background jobs and their job steps; and business process step nodes represent processing steps in business processes such as sales order creation, purchase order approval, material posting, or financial settlement.

[0077] Directed edges are used to represent directional relationships between nodes. These directed edges include object reference edges, program call edges, data read / write edges, interface transmission edges, job triggering edges, and business process mapping edges.

[0078] For example, when a pricing calculation object references the pricing context core data service view, an object reference edge is generated between the corresponding nodes; when an order processing program calls the credit check function module, a program call edge is generated between the corresponding nodes; when a pricing calculation object writes data to the order price result data table, a data write edge is generated between the corresponding nodes; when an order interface processing object sends a message to an external system, an interface transmission edge is generated; and when a business processing program triggers an order synchronization background job, a job trigger edge is generated.

[0079] Node status fingerprints are used to characterize the content status of a node under a specified system state. For change unit nodes, technical object nodes, and data object nodes, node status fingerprints can be generated based on the corresponding object content or data structure content and version identifier; for interface nodes, node status fingerprints can be generated based on the interface address, interface parameters, message structure, and interface configuration version; for background job nodes, node status fingerprints can be generated based on the job name, job steps, execution program, execution parameters, and scheduling configuration; for business process step nodes, node status fingerprints can be generated based on the business process mapping content and mapping version.

[0080] Node state fingerprints can be obtained using digest operations. For example, the normalized content and version identifier of a node are concatenated in a predetermined order, and a digest operation is performed on the concatenated result. Normalization processing may include standardizing character encoding, standardizing field order, and removing differences in spaces and line breaks that do not affect the object's execution result.

[0081] Evidence identifiers are used to point to the evidence records that generated the corresponding directed edges. Evidence records include object reference records, runtime call records, data access records, interface message records, or background job records. An evidence identifier must at least locate the system to which the evidence record belongs, the SAP client, the collection time, the collection session, and the record sequence number.

[0082] An impact path is a sequence of nodes that starts from the change unit node and proceeds along the verified directed edges to the affected node. The impact path can terminate at a data object node, interface node, background operation node, business process step node, or a pre-defined system boundary node.

[0083] Validation points are nodes set at specified locations along the impact path to collect transaction replay status and compare it with the expected status. Validation points include the first data write validation point, branch validation points, and merge validation points.

[0084] The first data writing node is the source node of the first data writing edge encountered along the direction of the influence path propagation, and the target node of this data writing edge is the data object node to be verified.

[0085] A branch node is a node with at least two outgoing edges that participate in the propagation of influence. A merge node is a node with at least two incoming edges that participate in the propagation of influence.

[0086] Candidate deviation nodes include source nodes called outside the path, unreached verification points, and verification points whose actual state differs from the expected state. Deviation nodes are the first candidate deviation nodes to appear, in the order of nodes that influence the path's propagation downstream from the self-changing unit.

[0087] An abnormal path is the impact path from a change unit in the current release batch to a deviated node.

[0088] The initial rollback set is a combination of change units selected from the change units in the abnormal path. Each abnormal path includes at least one selected change unit, and the combination contains the fewest change units.

[0089] The target rollback set is a set of change units obtained by expanding the initial rollback set according to object activation dependencies and version compatibility relationships.

[0090] A dormant edge is a directed edge that temporarily does not participate in the propagation of the influence, but retains the node relationships, node state fingerprints, and evidence records.

[0091] II. System Deployment Method

[0092] like Figure 1As shown, this embodiment provides an SAP closed-loop operation and maintenance system based on change impact maps, including a change analysis and map construction module, an impact path and verification point generation module, a release verification module, a deviation location and rollback module, and a map update module.

[0093] The Change Analysis and Graph Construction module is used to acquire and parse SAP change packages, identify change units, generate nodes and directed edges between nodes based on object reference records, run call records, data access records, interface message records, and background job records, construct a change impact graph, and bind source node status fingerprints, target node status fingerprints, client identifiers, and evidence identifiers to each directed edge.

[0094] The influence path and verification point generation module is used to verify the information of directed edge binding. It forms influence paths only along the directed edges that have passed verification, and sets verification points at the first data writing node, branch node and merging node in the influence path.

[0095] The release verification module is used to divide release batches based on shared verification points and direct object activation dependencies, import each release batch into the target system in sequence, perform transaction replay using desensitized inputs that maintain field associations, and collect call traces and verification point status.

[0096] The deviation location and rollback module is used to compare the call trajectory with the impact path, determine the candidate deviation node, deviation node and abnormal path, generate the initial rollback set, generate the target rollback set according to the object activation dependency and version compatibility relationship, and execute the rollback.

[0097] The graph update module is used to add directed edges, set dormant edges, and restore dormant edges based on cross-session call records.

[0098] The modules described above can be deployed on the same operations and maintenance server, or they can be deployed separately on the operations and maintenance management server, the graph database server, and the SAP system data acquisition terminal. Data can be transferred between modules via internal interfaces, message queues, or remote service interfaces.

[0099] The system can also be configured with a data storage area to store node records, edge records, evidence records, impact path records, verification point records, transaction replay records, call trajectory records, release batch records, snapshots before changes, and rollback records.

[0100] A node record must include at least the node identifier, node type, object type, object key, system to which it belongs, client identifier, current version, and current node status fingerprint.

[0101] A directed edge record includes at least the directed edge identifier, source node identifier, target node identifier, relationship type, source node state fingerprint, target node state fingerprint, client identifier, evidence identifier, and edge state. The edge state can include valid, pending verification, and dormant.

[0102] III. Specific Implementation of the Method of the Invention

[0103] like Figure 2 The diagram shows the general flow of the SAP closed-loop operation and maintenance method based on change impact map of the present invention, which will be described in detail below.

[0104] 3.1 Step S1: Constructing the change impact map

[0105] First, obtain the SAP change package, identify the change units, and construct a change impact map.

[0106] The system reads the transfer request identifier, transfer request type, object directory, object type, object key, source system identifier, target system identifier, client identifier, and object version information from the SAP change package.

[0107] If the same object is modified multiple times in an SAP change package, the current active version in the target system is determined as the version before the change, and the final version in the SAP change package that is to be imported into the target system is determined as the version after the change.

[0108] For multiple objects that need to be activated together and cannot be published independently, these objects can be combined into a single change unit. The combined change unit still retains the object type, object key, pre-change version, and post-change version of each component object.

[0109] After identifying the changed unit, the system collects static relationship records and dynamic relationship records respectively.

[0110] Static relationship records mainly include object reference records, type reference records between data dictionary objects, reference records between core data service views, correspondence records between enhancement implementations and enhancement points, and mapping records between business process steps and transaction entry points.

[0111] Dynamic relationship records mainly include runtime call records, data access records, interface message records, and background job records generated during program execution.

[0112] Runtime call logs can be obtained through program execution analysis tools, call stack collection programs, or runtime monitoring interfaces. Data access logs can be obtained through database access tracing functions. Interface message logs can be obtained from remote call logs, service call logs, or message processing logs. Background job logs can be obtained from job definitions, job steps, and job execution logs.

[0113] The system generates nodes and directed edges representing the relationships between nodes based on the above records.

[0114] For example, if an object reference record indicates that a pricing calculation class object references a pricing context core data service view, then a pricing calculation class object node, a pricing context core data service view node, and an object reference edge between the two are generated.

[0115] The execution call log shows that the order processing program calls the credit check function module, so an order processing program node, a credit check function module node, and the program call edge between the two are generated.

[0116] The data access record indicates that the pricing calculation object writes a record to the order price result data table, which generates a pricing calculation object node, an order price result data table node, and a data write edge pointing from the former to the latter.

[0117] For each directed edge, obtain the state content and version identifier of the source node and the target node when the evidence record is generated, and generate the state fingerprint of the source node and the state fingerprint of the target node.

[0118] Simultaneously, the client identifier and evidence identifier are recorded when the directed edge relationship is established. For cross-client objects, the client identifier can be set to a cross-client identifier; for client-related configuration records and client business data, the specific SAP client identifier is recorded.

[0119] Through the above processing, a change impact graph is formed, which includes nodes, directed edges, state fingerprints, and evidence identifiers.

[0120] To prevent the graph from expanding without boundaries, upper limits can be set for propagation levels, business process boundaries, or system boundaries. For example, when an impact propagates to an external interface that does not belong to the current business process, that interface can be designated as a boundary node; when an impact propagates to a basic component shared by a large number of business processes, only the successor nodes of that basic component that are relevant to the current business process can be retained.

[0121] 3.2 Step S2: Verify directed edges and set verification points

[0122] The system verifies the source node state fingerprint, target node state fingerprint, client identifier, and evidence record of each directed edge.

[0123] For the source node of a directed edge, read the current content and current version identifier of the corresponding node in the target system to generate the current source node state fingerprint; for the target node, generate the current target node state fingerprint in the same way.

[0124] When the source node state fingerprint of a directed edge is consistent with the current source node state fingerprint, the target node state fingerprint is consistent with the current target node state fingerprint, the client identifier is consistent with the target SAP client, and the evidence record has not been deleted, the record source system matches the system to which the nodes at both ends of the directed edge belong, and the collection time is within the preset validity period, the directed edge is deemed to have passed verification.

[0125] If any node's state fingerprint is inconsistent, or the client's identifier is inconsistent, the corresponding directed edge will be set as an edge to be verified, and it will not be allowed to participate in this impact propagation.

[0126] For directed edges between cross-client objects, the specific SAP client can be excluded; however, when one end of the directed edge is a client-related configuration record, it is still necessary to verify the client to which the corresponding configuration record belongs.

[0127] After the directed edge verification is completed, the directed traversal is performed along the verified directed edges, starting from the changed unit node, thereby forming the influence path.

[0128] Traversal can be performed using either depth-first traversal or breadth-first traversal. When a circular call relationship occurs, the loop entry point, loop exit point, and loop relationship are recorded, but already visited loop nodes are not expanded repeatedly within the same affected path.

[0129] Subsequently, the first data writing node, branch node, and merge node were identified in the impact path.

[0130] When the first data write edge is encountered along the influence path propagation direction, the source node of that data write edge is set as the first data write verification point, and the target data object node is determined as the data object node to be verified. The verification content can include whether the write occurred, the target data object, the record key, the write field, and the write result.

[0131] A node is designated as a branch verification point when it has at least two outgoing edges that participate in the propagation of influence. The verification content can include the expected successor branches, the successor branches that should not be entered, and the business field values ​​used to determine the branch.

[0132] A node is designated as a merge verification point when it has at least two incoming edges that participate in the propagation of influence. The verification content can include the actual arriving predecessor branch, the output data of each branch, and the business status after merging.

[0133] If there are no data writing nodes, branch nodes, or merge nodes in the affected path, then no verification point of the corresponding type will be set.

[0134] When the same node meets two or more verification point setting conditions at the same time, only one verification point is set, and the verification content corresponding to each setting condition is merged.

[0135] Configure business inputs, expected status, and snapshots before changes for each verification point.

[0136] Business inputs can be selected from business transactions that were successfully executed before the change. The expected state can be determined based on successful execution records before the change, business rules, and the baseline state of the target system.

[0137] The pre-change snapshot is generated before the release batch import. For SAP repository objects, the pre-change snapshot may include the active object version, object source code, object definition, and node status fingerprint; for client-related configuration records, the pre-change snapshot may include the configuration table name, configuration record key, client identifier, and configuration record value; for interface nodes, the pre-change snapshot may include the interface address, interface parameters, and message structure.

[0138] 3.3 Step S3: Divide the release batches and replay the transactions.

[0139] The system determines whether the impact paths corresponding to each change unit share the same verification point, and whether there is a direct object activation dependency between each change unit.

[0140] Direct object activation dependency means that the activation of an object corresponding to a change unit requires the use of the active version or runtime object of another change unit corresponding to the same object.

[0141] For example, if a pricing calculation object references a pricing context core data service view, and that core data service view in turn references a discount level data element, then there is a direct or sequential object activation dependency between the corresponding objects.

[0142] Change units that share the same verification point or have direct object activation dependencies are grouped into the same release batch, and the import order of each release batch is determined according to the direction of object activation dependencies.

[0143] The release batch containing the basic data structure object is imported first, while the release batch containing the program object that references the basic object is imported later.

[0144] Each release batch can import verification clients for the target SAP system. When it's necessary to limit the scope of impact, pre-defined application server groups can also be imported.

[0145] After importing and releasing the batch, the system uses de-identified input to perform transaction replay.

[0146] Anonymized input is obtained by replacing personal identification fields and sensitive business fields. During the replacement process, primary key and foreign key relationships, business document reference relationships, organizational structure mapping relationships, and SAP client fields are preserved.

[0147] For example, the same customer ID is always replaced with the same de-identified customer ID in the same test dataset; the sales order header and sales order items are still associated through the de-identified order number and item number; the sales organization, plant, and company codes are replaced according to the organization mapping relationship in the target verification client.

[0148] Each transaction replay generates a unique session identifier. The session identifier can consist of the SAP change package identifier, release batch identifier, target system identifier, client identifier, execution time, and session sequence number.

[0149] The system associates program call records, data read / write records, interface message records, background job records, and verification point status generated from the same transaction replay with a session identifier, thereby avoiding the mixing of records from different concurrent transactions.

[0150] If all transaction replays in the current release batch pass verification, then continue importing the next release batch; if there is an out-of-path call, the verification point is not reached, or the verification point status is inconsistent with the expected status, then pause the subsequent release batches and execute step S4.

[0151] 3.4 Step S4: Locate the off-target node and generate a rollback set

[0152] The system first maps the call traces corresponding to the same session identifier to the actual execution path based on the call time, call order, and parent call identifier.

[0153] For synchronous program calls, the node order can be determined based on the call time and the parent call identifier. For asynchronous interfaces or background jobs, the sequence can be established based on business document identifiers, message identifiers, job parameters, or associated session identifiers.

[0154] Subsequently, the actual execution path is compared with the affected path according to the order of the nodes in the affected path.

[0155] When the call relationship between adjacent nodes in the actual execution path is not included in the corresponding affected path, it is determined that an off-path call has occurred, and the source node that initiated the off-path call is identified as a candidate deviation node.

[0156] When a transaction replay is completed, if a verification point in the affected path does not generate a status record, that verification point is identified as a candidate deviation node.

[0157] When a verification point generates an actual state, but the actual state is inconsistent with the expected state, the verification point is also identified as a candidate deviation node.

[0158] Based on the order of nodes that propagate the influence path from the change unit downstream, the first candidate deviation node is determined as the deviation node.

[0159] After identifying the deviation node, extract the impact path to the deviation node from each change unit in the current release batch, and identify the extracted path as an abnormal path.

[0160] Subsequently, change units located on each abnormal path are extracted to form a candidate change unit set.

[0161] Change units are selected from the candidate change unit set, ensuring that each abnormal path includes at least one selected change unit. Among all change unit combinations that satisfy the above conditions, the combination with the fewest change units is determined as the initial rollback set.

[0162] When there are multiple combinations with the same number of change units, count the number of business process steps associated with each combination, and determine the combination with the fewest associated business process steps as the initial rollback set.

[0163] In one implementation, a branch and bound approach can be used to determine the initial backoff set. First, candidate change units are sorted in descending order of the number of abnormal paths they cover, and then the selection or rejection of the corresponding change units is determined sequentially. When the number of currently selected change units is not less than the number of optimal combinations already obtained, the expansion of the current combination is stopped.

[0164] After obtaining the initial fallback set, the initial fallback set is determined as the current expansion set, and expansion is performed according to object activation dependencies and version compatibility relationships.

[0165] The system checks whether restoring a change unit in the current extended set to its previous version will prevent change units outside the current extended set from activating and running together.

[0166] Version compatibility can include data type compatibility, field length compatibility, core data service view output field compatibility, interface parameter compatibility, and configuration reference compatibility.

[0167] When a change unit in the current extended collection is restored to the version before the change, resulting in missing referenced objects, mismatched data types or field lengths, incompatible core data service view output fields, inability to activate enhanced implementations, incompatible interface parameters, or non-existent objects or configuration keys referenced by configuration records, the corresponding associated change unit will be added to the current extended collection.

[0168] Repeat the above checks and additions until change units outside the current extended set can be activated and run together with the previous versions of each change unit within the current extended set.

[0169] The current expanded set is then determined as the target fallback set.

[0170] For SAP warehouse objects, the previous version can be restored by rolling back the transfer request; for client-related configuration records, the corresponding configuration records can be restored based on the snapshot before the change.

[0171] After the rollback is completed, the verification points associated with the target rollback set are re-executed. If the re-verification passes, the current release batch is marked as rolled back; if the re-verification still fails, the deviation node is re-determined based on the new call trajectory and verification point status.

[0172] 3.5 Step S5: Update the directed edge state

[0173] During the transaction replay process, the system also performs statistics on unrecorded call relationships.

[0174] Unrecorded call relationships refer to call relationships that exist in the actual call trajectory but do not have corresponding directed edges in the change impact graph.

[0175] When the source node, target node, call direction, client identifier, source node state fingerprint, and target node state fingerprint are all the same, they are determined to be the same call relationship.

[0176] When the same unrecorded call relationship is detected in transaction replays corresponding to at least two different session identifiers, cross-session accumulation is performed.

[0177] When the source node state fingerprint or the target node state fingerprint changes, the corresponding unrecorded call relationships are recounted.

[0178] When the cumulative number of cross-session calls for the same unrecorded call relationship reaches the threshold for adding a new edge while the node state fingerprint remains unchanged, a corresponding directed edge is added to the change impact graph, and the source node state fingerprint, target node state fingerprint, client identifier, and evidence identifier corresponding to each call are bound to the newly added directed edge.

[0179] Newly added directed edges will participate in the propagation starting from the next impact analysis, without changing the current release batch where the path generation has already been completed.

[0180] For an existing directed edge, if its source node is visited in multiple consecutive transaction replays, but the directed edge is not visited, and the number of consecutive visits reaches the dormant threshold, the directed edge is marked as a dormant edge.

[0181] Dormant edges do not participate in path generation, but retain their node relationships, state fingerprints, client identifiers, and historical evidence.

[0182] When the call relationship corresponding to the dormant edge reaches the threshold for adding new edges again, and the source node state fingerprint, target node state fingerprint, and client identifier are consistent with the target system current state fingerprint and the target SAP client, respectively, the dormant edge is restored as a directed edge participating in the propagation of influence.

[0183] IV. Examples

[0184] This example illustrates the change release process for SAP sales order pricing. The target system is the quality verification system, and the target SAP client is... .

[0185] SAP change packages to be released include Each change unit is denoted as... to .

[0186] To facilitate the explanation of the composition of each change unit, Table 1 lists each change unit and its main dependencies.

[0187] Table 1 Change Units in SAP Change Packages

[0188]

[0189] After the system reads the SAP change package, it determines the object reference record and the most recent... The impact of changes is mapped by analyzing the monthly runtime call records, data access records, interface message records, and background job records.

[0190] In the effective change impact graph before the change, the sales order creation transaction sequentially calls the order processing program, the pricing calculation class object, and the credit check function module.

[0191] The pricing calculation object reads the pricing context core data service view and writes the calculation result to the order price result data table. After the order is processed, the order interface processing object is called to perform an instant push based on business conditions, or the order synchronization job program is triggered to perform background batch synchronization.

[0192] like Figure 3 As shown, the change unit node sequentially forms an impact path through the technical object node, the pricing calculation object node, and the order processing node. This impact path branches into an interface processing path and a background operation path at the order processing node, and converges at the order status update node. In this change impact graph, the pricing calculation object is identified as the first data writing node, and the order price result data table is identified as the data object node to be verified; the order processing node is set as the branch verification point; and the order status update node is set as the convergence verification point.

[0193] In the change impact graph, the pricing calculation object is identified as the first data writing node, and the order price result data table is identified as the data object node to be verified; the position where the order processing program selects between the interface instant push path and the background batch synchronization path is set as the branch verification point; and the position where the two paths finally update the order processing status is set as the convergence verification point.

[0194] Based on shared verification points and direct object activation dependencies, the system divides each change unit into the following release batches:

[0195] , ,

[0196] in, This is the first batch of releases. This is the second batch of releases. This is the third batch of releases.

[0197] First batch of releases After importing into the target SAP system, the system is selected. Historical sales order entries that were successfully executed before the group change were anonymized.

[0198] During the de-identification process, customer ID, order ID, contact information, and amount details are replaced, but the reference relationship between order header and order items, the mapping relationship between sales organization and factory, and the association relationship between order items and pricing terms are retained.

[0199] The systems are respectively Each transaction replay generates a different session identifier and collects the call trajectory, data writing status, and verification point status corresponding to each session.

[0200] exist In the next transaction replay The actual execution path of the second transaction replay was consistent with the expected impact path; the rest In each transaction replay containing three discount levels, a call relationship was observed between the pricing calculation object and the tax standby calculation object.

[0201] This call relationship does not exist in the original change impact map, and is therefore identified as an unrecorded call relationship.

[0202] Upon first detecting an unrecorded call relationship, the system identifies the pricing calculation object that initiated the call as a candidate deviation node and continues to collect subsequent data status.

[0203] The transaction execution results show that the deviation between the actual after-tax net price and the expected after-tax net price in the order price results data table is:

[0204]

[0205] in, This represents the actual net price after tax written into the order price result data table after transaction replay; This indicates the expected net price after tax, determined based on the successful execution record prior to the change. This indicates the percentage deviation from the after-tax net price.

[0206] Since the unrecorded call relationship occurs before the first data write verification point, and the pricing calculation class object is the first candidate deviation node to appear in the actual execution path, the pricing calculation class object is identified as a deviation node, denoted as:

[0207]

[0208] The system extracts the first release batch. Each change unit in the middle is moved to the deviation node. The abnormal paths include:

[0209] , ,

[0210] The set of abnormal paths is:

[0211]

[0212] All three abnormal paths mentioned above contain change units. Therefore, the initial rollback set that can cover all abnormal paths and contains the fewest change units is:

[0213]

[0214] Determine the initial backoff set Then, it is used as the current extended collection, and the object activation dependencies and version compatibility are checked.

[0215] The system first checks the changed unit. Previous version and change unit Compatibility relationships between current versions.

[0216] Change Unit The previous version of the corresponding pricing calculation class object had a reference field length of [length missing]. The pricing context output field for the bit, and the change unit The current version outputs a discount level field with a length of 100%. Position. If only rollback... If the previous version of the pricing calculation class object is not activated and running together with the current version of the pricing context core data service view, then the previous version cannot be activated and run together with the current version of the pricing context core data service view.

[0217] Therefore, Adding to the current expanded set, we get:

[0218]

[0219] The system continues to check. Previous version and Compatibility relationships between current versions.

[0220] Change Unit The length of the referenced field in the previous version of the corresponding pricing context core data service view is [length missing]. Discount level data elements, and change units The current version has a field length of Bit.

[0221] If only rollback and ,but Previous version and The current version does not meet the field length compatibility requirements. Therefore, [the following will be implemented / required]. Adding to the current expanded set, we get:

[0222]

[0223] After performing the check again, the change unit outside the set to All are able to , and The previous version can be activated and run together without further expansion.

[0224] Therefore, the set The target rollback set has been determined as follows:

[0225]

[0226] The system generates a rollback set for the target based on the snapshot before the change. The rollback transmission request is executed, and the change unit is restored sequentially according to the dependency order between the discount level data element, the pricing context core data service view, and the pricing calculation class object. , and .

[0227] After the rollback is completed, the system will re-execute the aforementioned steps. Group-based de-identified business input. Re-verification results show that all... All group business inputs undergo status checks at the first data write verification point, branch verification point, and convergence verification point.

[0228] Second release batch and the third batch of releases The change unit was not rolled back. to It will remain in the target system.

[0229] For pricing calculation objects that call tax and fee standby calculation objects, the system does not record the call relationship. The call relationship was detected in all transaction replays with different session identifiers, and the source node state fingerprint and the target node state fingerprint remained unchanged.

[0230] The cumulative number of occurrences is recorded as ,but:

[0231]

[0232] Let the newly added edge threshold be denoted as In this embodiment, it is set as follows:

[0233]

[0234] because:

[0235]

[0236] The system adds a program call edge in the change impact graph that points from the pricing calculation object node to the tax and fee standby calculation object node, and binds a client identifier to this directed edge. Source node state fingerprint, target node state fingerprint and Evidence of the execution call.

[0237] The newly added directed edges participate in the propagation during the impact analysis of the subsequent revised SAP change package, so that the tax reserve calculation class object and its subsequent data access relationship are included in the scope of subsequent verification.

[0238] V. Comparative Verification

[0239] To illustrate the release verification and rollback results under different processing methods, three processing schemes are set up.

[0240] Option A uses manual reading of the SAP change package object list to determine the test scope, and rolls back the entire SAP change package after an anomaly is found.

[0241] Option B uses a static dependency graph that does not verify node status fingerprints and client identifiers to determine the scope of impact, and rolls back the entire release batch upstream of the deviating node after an anomaly is detected.

[0242] Solution C employs the method described in this embodiment.

[0243] Comparative verification uses A test SAP change package, each SAP change package includes... to Each change unit, each change package executes Group transaction replay.

[0244] The results of the three processing schemes are shown in Table 2.

[0245] Table 2 Validation results of different SAP operation and maintenance solutions

[0246]

[0247] As shown in Table 2, Scheme B does not verify the node state fingerprint and client identifier corresponding to the directed edge, and the dependency relationship corresponding to the historical object version may still participate in the propagation.

[0248] Solution C only forms influence paths along the verified directed edges, reducing the expansion of the test scope caused by expired dependencies.

[0249] Option C identifies deviation nodes by comparing the actual execution path with the affected path node by node, and uses the deviation nodes to limit abnormal paths, so that the average number of rollback change units is less than that of Option A and Option B.

[0250] Solution C further extends object activation dependencies and version compatibility relationships based on the initial rollback set, and no cases of objects failing to activate after rollback were observed during testing.

[0251] To further illustrate the processing relationship between the initial rollback set and the target rollback set, Table 3 shows the results of different rollback methods.

[0252] Table 3. Rollback Results of Sales Order Pricing Changes

[0253]

[0254] The above results indicate that the initial rollback set is used to narrow down the candidate rollback range for abnormal paths, while the target rollback set is used to ensure that the objects after rollback can be activated and run together.

[0255] V. Implementation Methods of Electronic Equipment

[0256] This embodiment also provides an electronic device, which includes a processor, a memory, and a communication interface.

[0257] The memory stores computer programs that can be executed by the processor. When the processor executes the computer program, it performs the following processes:

[0258] Obtain SAP change packages and identify change units;

[0259] Nodes and directed edges between nodes are generated based on object reference records, runtime call records, data access records, interface message records, and background job records to construct a change impact graph;

[0260] Verify directed edges and establish impact paths;

[0261] Set verification points in the affected path;

[0262] Divide the release batches and perform transaction replay;

[0263] Determine off-target nodes and abnormal paths based on the call trajectory and verification point status;

[0264] Generate the initial rollback set and the target rollback set, and execute the rollback;

[0265] Add directed edges, set dormant edges, or restore dormant edges based on cross-session call records.

[0266] The processor can be a server processor, a general-purpose central processing unit, or other processor capable of executing computer programs. Memory can include random access memory, read-only memory, solid-state memory, or disk storage.

[0267] The foregoing description of embodiments of the present invention, through which those skilled in the art are able to implement or use the present invention, will be readily apparent to those skilled in the art. Various modifications to these embodiments will be readily apparent to those skilled in the art. The general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novelty disclosed herein.

Claims

1. An SAP closed-loop operation and maintenance method based on change impact mapping, characterized in that, include: S1. Obtain the SAP change package and identify the change unit by object type, object key, and version before and after the change. Nodes and directed edges between nodes are generated based on object references, runtime calls, data access, interface messages, and background job records, forming a change impact graph. Source, target node state fingerprint, client identifier, and evidence identifier are bound to the directed edges. S2. Verify the state fingerprint, client identifier, and evidence record of the directed edges, and form an impact path only along the directed edges that have passed verification; set verification points at the first data writing node, branch node, and merge node; S3. Group shared verification points or change units with direct activation dependencies into the same batch and import them into the target system sequentially; use desensitized input replay transactions that maintain field associations, and associate call trajectories and verification point status by session; S4. Compare the call trajectory with the impact path, and take the source node of the call outside the path, the verification point that has not been reached or has an inconsistent state as the candidate deviation node, and take the first one as the deviation node. The path from the changed unit in this batch to the deviated node is taken as the abnormal path. The initial rollback set with the fewest units covering the abnormal path is selected. The rollback is then expanded into the target rollback set according to the activation dependency and version compatibility relationship. S5. When the node state fingerprint remains unchanged and the cumulative cross-session edge addition threshold is reached, a new directed edge is added for the same unrecorded call relationship. When the source node is visited and the edge is not visited consecutively and the dormancy threshold is reached, the edge is dormant and will be restored when the call relationship meets the new edge addition condition again.

2. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In step S1: The change unit is jointly identified by object type, object key, source system identifier, target system identifier, client identifier, version before change, and version after change. The client identifier is the SAP client identifier in the target SAP system. The change unit corresponds to an SAP warehouse object or client-related configuration record; The SAP warehouse objects include one or more of the following: ABAP programs, classes, function modules, data dictionary objects, core data service views, and enhanced implementations. The client-related configuration records are the configuration records in the configuration table associated with the target SAP client.

3. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In steps S1 and S2: The nodes include change unit nodes, technical object nodes, data object nodes, interface nodes, background operation nodes, and business process step nodes; The directed edges include object reference edges, program call edges, data read / write edges, interface transmission edges, job triggering edges, and business process mapping edges; The status fingerprints of change unit nodes, technical object nodes, and data object nodes are generated by the content and version identifier of the corresponding object or data structure. The status fingerprints of interface nodes, background job nodes, and business process step nodes are generated by the interface configuration, job definition, or business mapping content and the corresponding version identifier, respectively. The evidence identifier points to the object reference record, runtime call record, data access record, interface message record, or background job record that generated the corresponding directed edge; When the source node state fingerprint and target node state fingerprint of a directed edge are consistent with the current state fingerprint of the corresponding node in the target system, the client identifier is consistent with the target SAP client, the evidence record has not been deleted, the record source system matches the system to which the nodes at both ends of the directed edge belong and is within the preset validity period, the directed edge is deemed to have passed verification.

4. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In step S2: The first data writing node is the source node of the first data writing edge encountered along the direction of the influence path propagation, and the target node of the first data writing edge is the data object node to be verified. The branch node is a node with at least two outgoing edges participating in the propagation of influence, and the merging node is a node with at least two incoming edges participating in the propagation of influence. If no node of the corresponding type exists in the affected path, no verification point of that type is set; When the same node meets two or more verification point setting conditions at the same time, set a verification point on the node and merge the verification content corresponding to each setting condition. The expected state of the verification point is determined based on the business transactions successfully executed before the change. The snapshot of the verification point before the change includes one or more of the following: active object version, configuration record, data structure version, and interface configuration.

5. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In step S3: Change units that share the same verification point or have direct object activation dependencies in their corresponding impact paths are grouped into the same release batch, and the import order of each release batch is determined according to the direction of object activation dependencies. The direct object activation dependency is that the activation of an object corresponding to a change unit requires the use of the active version or runtime object of another change unit corresponding to the object. Import each release batch into the verification client or pre-defined application server group of the target SAP system; The de-identified input is obtained by replacing the personal identification field and sensitive business fields, while retaining the primary key and foreign key relationships, business document reference relationships, organizational structure mapping relationships, and SAP client fields; Session identifiers are used to associate program call records, data read / write records, interface message records, background job records, and verification point statuses generated during the same transaction replay.

6. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In step S4: Based on the call time, call order, and parent call identifier, the call trace corresponding to the same session identifier is mapped to the actual execution path; When the relationship between adjacent nodes in the actual execution path is not included in the corresponding affected path, the source node that initiates the external call to that path will be identified as a candidate deviation node. When a transaction replay is completed and no status record is generated at a verification point in the affected path, the verification point is identified as a candidate deviation node. When the actual state generated by the verification point is inconsistent with the expected state, the verification point is identified as a candidate deviation node. According to the order of nodes that propagate downstream from the corresponding impact unit, the first candidate deviation node is determined as the deviation node. Extract the change units located on each abnormal path in the current release batch to form a candidate change unit set. Select change units from the candidate change unit set so that each abnormal path contains at least one selected change unit. Determine the combination with the fewest change units as the initial rollback set. When there are multiple combinations with the same number of change units, the combination with the fewest associated business process steps is determined as the initial rollback set.

7. The SAP closed-loop operation and maintenance method based on change impact map according to claim 6, characterized in that, In step S4, the rollback after expanding the target rollback set according to activation dependencies and version compatibility relationships includes: The initial rollback set is determined as the current expansion set; Check the object activation dependencies and version compatibility relationships between change units in the current extended set and change units within the current release batch and outside the current extended set; When a change unit in the current extended collection is restored to the version before the change, it may cause the referenced object to be missing, the data type or field length to be mismatched, the core data service view output fields to be incompatible, the enhancement implementation to be unable to be activated, the interface parameters to be incompatible, or the object or configuration key referenced by the configuration record to be missing. In such cases, the associated change unit that has an object activation dependency or version compatibility relationship with the change unit that causes the corresponding state will be added to the current extended collection. Repeat the check and add operation until the change units outside the current extended set can be activated and run together with the previous versions of each change unit in the current extended set, and determine the resulting current extended set as the target rollback set; The SAP warehouse objects in the target rollback set can be restored by rolling back the transport request, or the client-related configuration records in the target rollback set can be restored based on the snapshot before the change, and the verification points associated with the target rollback set can be re-executed.

8. The SAP closed-loop operation and maintenance method based on change impact map according to claim 1, characterized in that, In step S5: The unrecorded call relationship refers to a call relationship that exists in the call trajectory but does not have a corresponding directed edge in the change impact graph; When the source node, target node, call direction, client identifier, source node status fingerprint, and target node status fingerprint are all the same, they are determined to be the same call relationship; The cross-session accumulation refers to the detection and cumulative counting of the same call relationship in the transaction replays corresponding to at least two different session identifiers; When the source node state fingerprint or the target node state fingerprint changes, the corresponding unrecorded call relationships are recounted. When a source node is visited in multiple consecutive transaction replays, but the corresponding directed edge is not visited, and the number of consecutive visits reaches the sleep threshold, the directed edge is marked as a sleep edge that does not participate in the propagation of influence. When the call relationship corresponding to the dormant edge reaches the threshold for adding new edges again, and the source node state fingerprint, target node state fingerprint, and client identifier are consistent with the current state fingerprint of the target system and the target SAP client, respectively, the dormant edge will be restored as a directed edge participating in the influence propagation.

9. An SAP closed-loop operation and maintenance system based on change impact mapping, characterized in that, This system is used to implement the SAP closed-loop operation and maintenance method according to any one of claims 1 to 8, including: The Change Analysis and Graph Construction module is used to parse SAP change packages, identify change units, generate nodes and directed edges between nodes, construct a change impact graph, and bind source node state fingerprints, target node state fingerprints, client identifiers, and evidence identifiers to the directed edges. The influence path and verification point generation module is used to verify directed edges, form influence paths, and set verification points in the influence paths; The release verification module is used to divide release batches, import change units, replay transactions, and collect call trajectories and verification point status. The deviation positioning and rollback module is used to determine deviation nodes and abnormal paths, generate an initial rollback set and a target rollback set, and execute the rollback. The graph update module is used to add directed edges, set dormant edges, and restore dormant edges.

10. An electronic device, characterized in that, The system includes a processor, a memory, and a computer program stored in the memory and executable by the processor. When the processor executes the computer program, it implements the SAP closed-loop operation and maintenance method based on the change impact map as described in any one of claims 1 to 8.

Images