Method and device for realizing revocation operation in software system, server and storage medium
By dividing the undo process in the software system into multiple independent undo stages and creating a list of undo information carriers and executors, the problem of highly coupled undo operation logic in the prior art is solved, and a more flexible and easy-to-manage undo operation is achieved.
Patent Information
- Application Number
- CN202411604525.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-11
- Publication Date
- 2025-03-04
AI Technical Summary
When existing software systems implement undo operations, the design logic between each undo operation is highly coupled, resulting in an error in a certain undo operation, which may cause the entire undo process to fail, increasing the difficulty of troubleshooting and repairing.
By dividing the revocation process into multiple independent revocation stages based on the correspondence between the business process and the revocation process, each revocation stage contains a specific revocation method, creating and initializing the revocation information carrier and revocation executor list, thereby determining the revocation stage to be executed and executing the corresponding revocation method.
It reduces the coupling between each undo stage and reduces the interdependence between each undo stage, so that errors occur in one undo stage will not affect the execution of other undo stages, and improves the flexibility and maintainability of undo operations.
Smart Images
Figure CN119557030A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a method, device, server and storage medium for implementing an undo operation in a software system. Background Art
[0002] With the continuous expansion of corporate business and the surge in transaction frequency, the stability and reliability of software systems, as the core support for corporate operations, have become the focus of corporate attention. Among them, undo operations, as an indispensable part of the software system, play a vital role in ensuring the accuracy and integrity of business processes.
[0003] However, the design logic of each revocation operation in the current software system is highly coupled when implementing the revocation process. Once an error occurs in a revocation operation in the software system, it often causes corresponding errors in other revocation operations, and even causes the entire revocation process to fail. For example, in an online shopping system, revocation operations include payment revocation, order status update, inventory recovery, etc. The design logic of these revocation operations is highly coupled. When an error occurs in the order status update, it will cause corresponding errors in payment revocation and inventory recovery, causing the entire revocation process to fail.
[0004] This design limits the adaptability and maintainability of the software system. The highly coupled undo operations make it difficult for the system to adapt to the undo requirements of different businesses, and once a problem occurs at a certain undo stage, it may affect the entire process, increasing the difficulty of troubleshooting and repairing. Summary of the invention
[0005] Based on the above problems, the present application provides a method, device, server and storage medium for implementing undo operations in a software system.
[0006] The embodiments of the present application disclose the following technical solutions:
[0007] In a first aspect, the present application provides a method for implementing an undo operation in a software system, the method comprising:
[0008] Receiving a cancellation request initiated by a user device through a software system; the cancellation request is used to indicate cancellation of a completed first business process;
[0009] Based on the correspondence between the business process and the cancellation process, determining a first cancellation process corresponding to the first business process;
[0010] Dividing the first revocation process into a plurality of independent revocation stages based on the service revocation rules in the software system, each revocation stage including a corresponding revocation method;
[0011] Create and initialize the revocation information carrier and the revocation executor list;
[0012] determining a revocation stage to be executed from the plurality of revocation stages;
[0013] Obtaining the revocation information required for the revocation phase to be executed and adding it to the revocation information carrier;
[0014] Adding the revocation method corresponding to the revocation stage to be executed to the revocation executor list;
[0015] The revocation methods in the revocation executor list are executed based on the revocation information in the revocation information carrier.
[0016] In an optional implementation, the revocation information required for the revocation phase to be executed includes multiple types of revocation information;
[0017] The step of creating and initializing a cancellation information carrier includes:
[0018] Creating a revocation information carrier;
[0019] The revocation information carrier is initialized through a builder pattern; the builder pattern supports the revocation information carrier to add multiple types of revocation information.
[0020] In an optional implementation, the revocation request includes first identification information, and the first identification information indicates a revocation stage to be executed;
[0021] Each revocation stage also includes corresponding unique identification information, and the unique identification information is used to uniquely refer to the corresponding revocation stage.
[0022] In an optional implementation, determining the revocation stage to be executed from the multiple revocation stages includes:
[0023] Traversing the unique identification information of the multiple revocation stages;
[0024] The revocation stage in which the unique identification information matches the first identification information in the revocation request is determined as the revocation stage to be executed.
[0025] In an optional implementation, executing the revocation method in the revocation executor list based on the revocation information in the revocation information carrier includes:
[0026] According to the order of the revocation methods in the revocation executor list, the revocation information required for the corresponding revocation stage in the revocation information carrier is transferred into the revocation executor list one by one;
[0027] The undo method corresponding to the corresponding undo stage in the undo executor list is executed based on the incoming undo information.
[0028] In an optional implementation, after receiving the cancellation request initiated by the user equipment through the software system, the method further includes:
[0029] Obtaining a revocation condition according to the service revocation rule in the software system; the revocation condition is a condition that needs to be met when executing the revocation request;
[0030] The revocation request is verified based on the revocation condition; if the revocation request meets the revocation condition, the revocation verification passes; if the revocation request does not meet the revocation condition, the revocation verification fails.
[0031] In an optional implementation, after the revocation check fails, the method further includes:
[0032] Outputting exception information and intercepting the revocation request, the exception information including a revocation condition that the revocation request does not meet.
[0033] A second aspect of the present application provides a device for implementing an undo operation in a software system, the device comprising:
[0034] A receiving module, used to receive a cancellation request initiated by a user device through a software system; the cancellation request is used to indicate the cancellation of a completed first business process;
[0035] A revocation process determination module, configured to determine a first revocation process corresponding to the first business process based on the correspondence between the business process and the revocation process;
[0036] A revocation stage division module, used to divide the first revocation process into a plurality of independent revocation stages based on the business revocation rules in the software system, each revocation stage including a corresponding revocation method;
[0037] A creation and initialization module, used for creating and initializing a revocation information carrier and a revocation executor list;
[0038] A to-be-revoked stage determination module, used to determine a to-be-revoked stage from the multiple revocation stages;
[0039] A first adding module, used for acquiring the revocation information required for the revocation phase to be executed and adding it to the revocation information carrier;
[0040] A second adding module, used for adding the revocation method corresponding to the revocation stage to be executed to the revocation executor list;
[0041] A revocation module is used to execute the revocation method in the revocation executor list based on the revocation information in the revocation information carrier.
[0042] A third aspect of the present application provides a server for implementing an undo operation in a software system, the server comprising:
[0043] a memory having a computer program stored thereon;
[0044] A processor is used to execute the computer program in the memory to implement the steps of the method for implementing an undo operation in a software system introduced in any implementation manner of the first aspect.
[0045] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for implementing an undo operation in a software system introduced in any implementation manner of the first aspect.
[0046] Compared with the prior art, this application has the following beneficial effects:
[0047] In the technical solution of the present application, a revocation request is first received from a user device through a software system, and the revocation request is used to indicate the revocation of a completed first business process; then, based on the correspondence between the business process and the revocation process, a first revocation process corresponding to the first business process is determined; secondly, based on the business revocation rules in the software system, the first revocation process is divided into multiple independent revocation stages, and each revocation stage includes a corresponding revocation method; a revocation information carrier and a revocation executor list are created and initialized again; then a revocation stage to be executed is determined from multiple revocation stages; in addition, the revocation information required for the revocation stage to be executed is obtained and added to the revocation information carrier; at the same time, the revocation method corresponding to the revocation stage to be executed is added to the revocation executor list; finally, the revocation method in the revocation executor list is executed based on the revocation information in the revocation information carrier.
[0048] In the technical solution of the present application, the revocation process is flexibly divided into multiple independent revocation stages based on the business revocation rules in the software system. Each revocation stage has its own specific revocation method, which reduces the coupling between the revocation stages and reduces the mutual dependence between the revocation stages. When an error occurs in one revocation stage, it will not affect the execution of other revocation stages, making the revocation operation more flexible and easy to manage and maintain. In this solution, different revocation methods can be added according to different business needs through the revocation executor list, thereby enhancing the flexibility of the revocation operation. This helps to adapt to different business scenarios and changing needs. BRIEF DESCRIPTION OF THE DRAWINGS
[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0050] Figure 1 A flowchart of a method for implementing an undo operation in a software system provided in an embodiment of the present application;
[0051] Figure 2 A schematic diagram of a scenario for implementing an undo operation in a software system provided in an embodiment of the present application;
[0052] Figure 3 A schematic diagram of the structure of a device for implementing an undo operation in a software system provided in an embodiment of the present application. DETAILED DESCRIPTION
[0053] As described above, the current undo operation is an indispensable part of the software system and plays a vital role in ensuring the accuracy and integrity of the business process. However, the design logic between the undo operations in the current software system is highly coupled when implementing the undo process. Once an undo operation in the software system fails, it often causes corresponding errors in other undo operations, and even causes the entire undo process to fail, increasing the difficulty of troubleshooting and repairing.
[0054] After research, the inventor proposed a method, device, server and storage medium for implementing the revocation operation in the software system. First, a revocation request initiated by a user device through the software system is received, and the revocation request is used to indicate the revocation of the completed first business process; then, based on the correspondence between the business process and the revocation process, the first revocation process corresponding to the first business process is determined; secondly, based on the business revocation rule in the software system, the first revocation process is divided into multiple independent revocation stages, and each revocation stage contains a corresponding revocation method; the revocation information carrier and the revocation executor list are created and initialized again; then the revocation stage to be executed is determined from multiple revocation stages; in addition, the revocation information required for the revocation stage to be executed is obtained and added to the revocation information carrier; at the same time, the revocation method corresponding to the revocation stage to be executed is added to the revocation executor list; finally, the revocation method in the revocation executor list is executed based on the revocation information in the revocation information carrier. The coupling between the various revocation stages is reduced, making the revocation operation more flexible.
[0055] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0056] See also Figure 1 , which is a flow chart of a method for implementing an undo operation in a software system provided by an embodiment of the present application. Figure 1 As shown, the method comprises the following steps:
[0057] S101: Receive a cancellation request initiated by a user device through a software system, where the cancellation request is used to instruct cancellation of a completed first business process.
[0058] User devices refer to terminal devices used to interact with software systems. User devices can be smartphones, tablets, personal computers (including desktops and laptops), smart watches, and any other devices that can connect to the Internet and execute software applications. Users interact with software systems through applications on these devices (such as food delivery apps, online shopping platforms, banking apps, etc.) and initiate various requests, including cancellation requests.
[0059] A software system is a collection of programs running on a server or user device that processes user requests, manages data, executes business logic, etc. In the fields of food delivery, online shopping, financial services, etc., software systems usually include a front-end user interface (such as an app or web page), a back-end server (processing business logic and data storage), a database (storing user information, order data, etc.), and possibly other components. The software system receives requests sent by user devices, processes them according to business logic, and then returns the results to the user device.
[0060] In an embodiment of the present application, a revocation request is a specific type of request initiated by a user through a software system on a user device, which is used to indicate that a certain business process that has been completed previously is desired to be revoked or canceled. For the sake of clarity, the previously completed business process that the revocation request indicates is desired to be revoked or canceled will be referred to as the first business process.
[0061] A business process refers to a collection of orderly activities or operations performed to achieve a specific goal or task. For example, in a food delivery software, a business process may be a whole process from the user placing an order to the deliveryman delivering the food and confirming completion; in an online shopping platform, a business process may be a whole process from the user purchasing the goods to the goods being shipped and confirming receipt. Business processes usually contain multiple steps and states, such as order creation, payment, shipment, harvesting, evaluation, etc. When a business process reaches a certain end state (such as the "completed" state), the user may want to cancel the previously completed first business process for various reasons. At this time, a cancellation request needs to be initiated through the software system. For example, when the order has been paid but the goods have not been shipped, the user initiates a cancellation request at this time, and the current completed order creation and order payment are the first business process.
[0062] S102: Based on the correspondence between the business process and the cancellation process, determine a first cancellation process corresponding to the first business process.
[0063] In the embodiment of the present application, each business process has its corresponding revocation process. The revocation process is the reverse operation of the business process, which can revoke or cancel the completed business process. This correspondence ensures that when a business process needs to be revoked, the corresponding revocation process can be quickly found and executed.
[0064] According to the first business process determined in the previous step, based on the correspondence between the business process and the revocation process, a first business revocation process corresponding to the first business process can be determined to complete the revocation operation subsequently.
[0065] S103: Divide the first revocation process into multiple independent revocation stages based on the business revocation rules in the software system, and each revocation stage includes a corresponding revocation method.
[0066] In the embodiment of the present application, the service cancellation rule refers to a series of rules and standards formulated in the software system to regulate and manage the service cancellation process, aiming to ensure the accuracy, compliance and efficiency of the cancellation operation.
[0067] Based on the business revocation rules in the software system, the first revocation process is divided into multiple independent revocation stages. Each revocation stage has its own specific revocation method, which can be understood as a revocation logic. For example, these revocation stages may involve database operations, file system cleanup, notification sending, etc. Because each stage is designed as an independent stage, even if the subsequent process fails, the previous revocation action will not be affected.
[0068] In the embodiment of the present application, this step can be handled by defining a private method in the software system to handle the various cancellation stages of the cancellation process. This method will contain the cancellation logic corresponding to each stage, such as canceling an order, deleting related records, etc.
[0069] In an example implementation, the process can be implemented by the following code framework:
[0070] private void discardStageOne(DiscardDTO dto){
[0071] / / Cancel logic for phase 1, such as canceling orders, deleting related records, etc.
[0072] }
[0073] private void discardStageTwo(DiscardDTO dto){
[0074] / / Cancellation logic for phase 2, such as canceling payment, refunding, etc.
[0075] }
[0076] …
[0077] Among them, DiscardDTO (Data Transfer Object) is used to encapsulate the data to be passed to this method.
[0078] S104: Create and initialize a revocation information carrier and a revocation executor list.
[0079] In the embodiment of the present application, a revocation information carrier is created to encapsulate the data and status required in the revocation operation process, and an empty revocation executor list is initialized to store the revocation methods corresponding to each revocation stage.
[0080] In the embodiment of the present application, the revocation executor list is List <Consumer <t>>, where Consumer <t>It is a functional interface introduced in Java 8 and is part of the java.util.function package. It represents a function that receives a single input parameter but does not return any result. In Java functional programming, it is often used to consume data.
[0081] accept(T t) is the interface Consumer <t>A method in which the parameter is a carrier of cancellation information. This method provides a concise way to process data without returning any value.
[0082] S105: Determine a revocation stage to be executed from multiple revocation stages.
[0083] Depending on the business process, it may not be necessary to execute all the undo stages when completing the undo operation. Therefore, before executing the undo stage, the undo stage to be executed is first determined from multiple undo stages so that subsequent undo operations are more efficient and accurate.
[0084] S106: Obtain the revocation information required for the revocation phase to be executed and add it to the revocation information carrier.
[0085] Based on the undo stage to be executed determined in the previous step, the undo information required for the undo stage to be executed is obtained and the undo information is added to the undo information carrier that has been created and initialized.
[0086] S107. Add the revocation method corresponding to the revocation phase to be executed to the revocation executor list.
[0087] Based on the determined undo stage to be executed, the undo method corresponding to the undo stage to be executed is added to the undo executor list.
[0088] S108: Execute the revocation method in the revocation executor list based on the revocation information in the revocation information carrier.
[0089] In the embodiment of the present application, the revocation methods corresponding to all revocation stages that need to be executed are run by the revocation executor.
[0090] In one example implementation, this operation can be performed using Java 8's Lambda expressions and method references.
[0091] In the embodiment of the present application, the revocation process is flexibly divided into multiple independent revocation stages based on the business revocation rules in the software system, and each revocation stage has its own specific revocation method, which reduces the coupling between the revocation stages and reduces the mutual dependence between the revocation stages, so that when an error occurs in one revocation stage, it will not affect the execution of other revocation stages, making the revocation operation more flexible and easy to manage and maintain. In this solution, different revocation methods can be added according to different business needs through the revocation executor list, thereby enhancing the flexibility of the revocation operation. This helps to adapt to different business scenarios and changing needs.
[0092] Optionally, the revocation information required for the revocation phase to be executed includes multiple types of revocation information. The above process of creating and initializing the revocation information carrier includes:
[0093] Creating a revocation information carrier;
[0094] Initialize the revocation information carrier through the builder pattern.
[0095] The Builder pattern is a software engineering design pattern used to solve the problem of constructing complex objects, especially when the creation of an object requires multiple steps or parameter combinations. The Builder pattern supports the undo information carrier to add multiple types of undo information.
[0096] In an example implementation, this process can be implemented by the following code framework:
[0097] public class DiscardDTO {
[0098] / / DTO attributes, such as transaction code, status, etc.
[0099] private String tradeCode;
[0100] private String status;
[0101] / / More properties...
[0102] / / More getters and setters...
[0103] }
[0104] class DiscardDTOBuilder{
[0105] private DiscardDTO discardDTO;
[0106] public DiscardDTOBuilder(){
[0107] discardDTO=new DiscardDTO();
[0108] }
[0109] public DiscardDTOBuilder setTradeCode(String tradeCode){
[0110] discardDTO.setTradeCode(tradeCode);
[0111] return this;
[0112] }
[0113] / / More settings...
[0114] public DiscardDTO build(){
[0115] return discardDTO;
[0116] }
[0117] }
[0118] Among them, the DTO attribute indicates the type of revocation information.
[0119] In the embodiment of the present application, the builder pattern is used to initialize the revocation information carrier, thereby improving the reusability and scalability of the revocation code framework. In the process of implementing the revocation operation, the existing builder class can be reused to create a new revocation information carrier without repeatedly writing code. At the same time, if it is necessary to add a new type of revocation information or modify the existing revocation information, it is only necessary to make corresponding adjustments in the builder class without modifying the core logic of the revocation operation, making the construction process of the revocation information more flexible and controllable.
[0120] Optionally, the revocation request includes first identification information, and the first identification information indicates the revocation stage to be executed. Each revocation stage also includes corresponding unique identification information, and the unique identification information is used to uniquely refer to the corresponding revocation stage.
[0121] Optionally, the above step S105 includes:
[0122] Unique identification information that traverses multiple revocation stages;
[0123] The revocation stage whose unique identification information matches the first identification information in the revocation request is determined as the revocation stage to be executed.
[0124] In the embodiment of the present application, the multiple independent revocation stages divided in step S103 are traversed, and the unique identification information of each revocation stage is checked one by one. For each revocation stage traversed, its unique identification information is compared with the first identification information in the revocation request. If matching unique identification information is found, that is, the revocation stage is identified as being consistent with the revocation stage to be executed specified in the revocation request, then the stage is determined as the revocation stage to be executed.
[0125] In an exemplary implementation, the first identification information may be a transaction code or other business-critical data. Taking the transaction code as an example, the above process may be implemented through the following code framework:
[0126] private List <Consumer <discarddto>>registerOperations(String tradeC-ode,DiscardDTo dto){
[0127] List<Consumer <discarddto>>operations=new ArrayList<>();
[0128] / / Determine whether to execute phase 1 based on the transaction code
[0129] if(requiresStageOne(tradeCode)){
[0130] operations.add(this::discardStageOne);
[0131] }
[0132] / / Determine whether to execute phase 2
[0133] if(requiresStageTwo(tradeCode)){
[0134] operations.add(this::discardStageTwo);
[0135] }
[0136] / / More stage checks and registrations...
[0137] return operations;
[0138] }
[0139] Optionally, if no matching unique identification information is found after traversing all revocation stages, an error message may be returned or other error handling processes may be executed (such as prompting the user that the revocation request is invalid or the specified revocation stage does not exist).
[0140] Optionally, the above step S108 includes:
[0141] According to the order of the revocation methods in the revocation executor list, the revocation information required for the corresponding revocation stage in the revocation information carrier is transferred to the revocation executor list one by one;
[0142] Execute the undo method corresponding to the corresponding undo stage in the undo executor list based on the incoming undo information.
[0143] In an embodiment of the present application, the executors in the revocation executor list may adopt a strategy pattern to execute corresponding revocation phases one by one according to the method references in the revocation executor list, wherein the information required for revocation is passed in through a revocation information carrier.
[0144] Among them, the strategy pattern defines a series of algorithms and encapsulates each algorithm so that they can be interchanged. The strategy pattern makes the algorithm independent of the client that uses it.
[0145] Method references allow you to reference methods or constructors of existing Java classes or objects without specifying the method name.
[0146] In an example implementation, the undo executor list may be implemented by the following code framework:
[0147] Private DiscardDTO doDiscard(String tradeCode){
[0148] / / Create an instance of the undo information carrier
[0149] DiscardDTO discardDTO=new DicardDTOBuilder()
[0150] .setTradeCode(tradeCode)
[0151] . / / Set more properties...
[0152] .build();
[0153] / / Register the undo method that needs to be executed
[0154] List <Consumer <discarddto>>consumer=registerOperations(trade
[0155] -Code,discardDTO);
[0156] / / Execute all registered operations
[0157] for(Consumer <discarddto>operation:consumers){
[0158] operation.accept(discardDTO);
[0159] }
[0160] Return discardDTO;
[0161] }
[0162] In the embodiment of the present application, the execution of the undo phase is implemented by using the strategy pattern and method reference, so that a new undo phase can be added without modifying the existing code, thereby improving the scalability of the system.
[0163] Before executing the revocation operation, it is crucial to ensure the legitimacy of the revocation operation. Therefore, in an optional implementation, after the above step S101, the method for implementing the revocation operation in the software system further includes:
[0164] Obtaining a revocation condition according to the service revocation rule in the software system; the revocation condition is a condition that needs to be met when executing the revocation request;
[0165] The revocation request is verified based on the revocation conditions; if the revocation request meets the revocation conditions, the revocation verification passes; if the revocation request does not meet the revocation conditions, the revocation verification fails.
[0166] In the embodiments of the present application, specific rules for service revocation can be specified based on business requirements and system design. These service revocation rules generally cover the types of operations that can be revoked, time limits for revocation, related status checks, authority requirements, etc. Based on these service revocation rules, revocation conditions can be refined, i.e., specific requirements that need to be met when executing a revocation request.
[0167] In an example implementation, the time limit includes that the cancellation request should be made within a certain time period after the operation is completed, for example, within 24 hours; the status check includes that the object of the cancellation operation should be in a certain state, such as the order has not been paid, the task has not been started, etc.; the permission requirement includes that the user or role initiating the cancellation request should have specific permissions.
[0168] In an example implementation, when a revocation request is received, key information of the revocation request can be parsed, such as the operation class, operation object ID, request time, etc. Then, it is checked whether the user or role that initiated the revocation request has the authority to perform the operation. Then, it is verified whether the current state of the operation object meets the state requirements in the revocation condition, and it is checked whether the revocation request is made within the specified time range. If the revocation request meets all the revocation conditions, the revocation check passes, the system executes the revocation operation, and updates the relevant status and data.
[0169] If the revocation request does not satisfy one or more revocation conditions, the revocation check fails.
[0170] In an exemplary implementation, taking checking the transaction status as an example, the revocation verification operation can be implemented by the following code framework:
[0171]
[0172] Optionally, after the revocation check fails, an exception message may be output and the revocation request may be intercepted. The exception message includes the revocation condition that the revocation request does not meet.
[0173] In an example implementation, the exception information is recorded with detailed log information to facilitate subsequent auditing and troubleshooting.
[0174] Figure 2 A schematic diagram of a scenario for implementing an undo operation in a software system provided in an embodiment of the present application. Figure 2 Provide further explanation of this undo operation method.
[0175] See also Figure 2 ,The same software system will be available to multiple users, and each user may initiate a revocation request to the software system on his / her device, and the completed processes when the revocation request is initiated may also be different. Figure 2 The revocation request 1, revocation request 2, etc. in the revocation request represent different revocation requests initiated by different users through their respective user devices. The first business processes corresponding to these revocation requests may be the same or may be different.
[0176] Different revocation requests can be passed in through a unified entry. After receiving the revocation request, the revocation request is first verified to see if it meets the revocation conditions. If the revocation request does not meet the revocation conditions, the subsequent revocation process is blocked; if the revocation request meets all revocation conditions, the first revocation process corresponding to the first business process indicated by the revocation request is divided into multiple independent revocation stages. For example, Figure 2 The figure shows the five independent revocation stages obtained through division, namely, revocation stage A, revocation stage B, revocation stage C, revocation stage D, and revocation stage E. In actual situations, the independent revocation stages divided may be more Figure 2 There are more undo stages shown, and there may be more than Figure 2 There are fewer undo stages shown. Figure 2 The revocation stages shown in are only examples and do not constitute a limitation on the technical solution of the present application.
[0177] Create and initialize the revocation information carrier and the revocation executor list List <Consumer <t>>. Figure 2 As shown in the starting end of the evolution arrow, the revocation information carrier and the revocation executor list after initialization are empty.
[0178] Afterwards, the undo stage to be executed in the divided independent undo stages is determined according to the relevant identifier, the undo information required for the undo stage to be executed is added to the undo information carrier, and the undo method corresponding to the undo stage to be executed is added to the undo executor list. The undo executor implements the execution of the undo operation through the strategy mode and method index. Figure 2 As shown at the end of the evolution arrow at the corresponding position in , the revocation executor list evolves from empty to a revocation executor list filled with the revocation stage A method index, the revocation stage B method index, and the revocation stage D method index, and the revocation information carrier evolves from empty to a revocation information carrier filled with the revocation information required for stage A, the revocation information required for stage B, and the revocation information required for stage D.
[0179] Finally, perform the undo operation. Figure 2 As shown, the undo operation is performed by traversing the undo executor list List <Consumer <t>>, use Consumer <t>The method accept(T t) in the interface consumes the parameter t passed in, where the parameter t passed in is the information required for revocation taken out from the revocation information carrier, so as to implement the revocation operation.
[0180] Optionally, with respect to the update and maintenance of the undo operation method implemented in the software system proposed in the present application, if a new undo process needs to be added later, a corresponding undo stage is added when maintaining the undo function, and a judgment logic is added to the code framework for confirming the undo method, and the rest does not need to be changed; if the newly added undo process does not need to execute an existing undo stage, the undo function does not need to be changed; if the mode of a certain undo stage needs to be modified, the undo stage can be split according to the actual situation, or the logic of the undo stage in the code framework can be changed, and the rest does not need to be changed.
[0181] In the embodiment of the present application, firstly, by dividing the undo process into multiple independent undo stages, each stage focuses on undoing a specific action, thereby reducing the coupling between the various undo stages, so that modifications to a single undo stage will not affect other parts, thereby facilitating independent testing and maintenance.
[0182] By using the builder pattern to initialize the undo information carrier, the construction process of the undo information is made more flexible and controllable. By using identification information to determine which stages need to be undone, the undo logic can be dynamically adjusted according to different business scenarios, enhancing the flexibility of the system. The execution of the undo stage is implemented by using the strategy pattern and method reference. This design allows the addition of new undo stages without modifying the existing code, improving the scalability of the system.
[0183] At the same time, by clearly separating the logic of the undo operation from the execution of the undo operation, the former is responsible for determining which stages need to be undone, and the latter is responsible for performing specific undo operations. This separation makes the code clearer and reduces the difficulty of code understanding and maintenance.
[0184] Based on the method for implementing the undo operation in the software system provided in the aforementioned embodiment, the present application also provides a device for implementing the undo operation in the software system. Figure 3 The present invention provides a schematic diagram of a device for implementing a revocation operation in a software system. Figure 3 As shown, the device for implementing the undo operation in the software system includes:
[0185] The receiving module 301 is used to receive a cancellation request initiated by a user device through a software system; the cancellation request is used to indicate the cancellation of a completed first business process.
[0186] The cancellation process determination module 302 is used to determine a first cancellation process corresponding to the first business process based on the correspondence between the business process and the cancellation process.
[0187] The cancellation stage division module 303 is used to divide the first cancellation process into multiple independent cancellation stages based on the business cancellation rules in the software system, and each cancellation stage includes a corresponding cancellation method.
[0188] The creation and initialization module 304 is used to create and initialize the revocation information carrier and the revocation executor list.
[0189] The to-be-revoked stage determining module 305 is used to determine the to-be-executed revocation stage from the multiple revocation stages.
[0190] The first adding module 306 is used to obtain the revocation information required by the revocation phase to be executed and add it to the revocation information carrier.
[0191] The second adding module 307 is used to add the revocation method corresponding to the revocation stage to be executed to the revocation executor list.
[0192] The revocation module 308 is configured to execute the revocation method in the revocation executor list based on the revocation information in the revocation information carrier.
[0193] In the embodiment of the present application, the revocation process is divided into multiple independent revocation stages through the revocation stage division module 303, and each revocation stage has its own specific revocation method, which reduces the coupling between the revocation stages and reduces the mutual dependence between the revocation stages, so that when an error occurs in one revocation stage, it will not affect the execution of other revocation stages, making the revocation operation more flexible and easy to manage and maintain. Different revocation methods can be added according to different business needs through the revocation executor list, thereby enhancing the flexibility of the revocation operation. This helps to adapt to different business scenarios and changing needs.
[0194] In an optional implementation, the revocation information required for the revocation phase to be executed includes multiple types of revocation information. The creation and initialization module 304 is specifically used to: create a revocation information carrier; initialize the revocation information carrier through a builder mode; the builder mode supports the revocation information carrier to add multiple types of revocation information.
[0195] In an optional implementation, the revocation request includes first identification information, the first identification information indicates the revocation stage to be executed; each revocation stage also includes corresponding unique identification information, the unique identification information is used to uniquely refer to the corresponding revocation stage. The revocation stage determination module 305 is specifically used to: traverse the unique identification information of multiple revocation stages; determine the revocation stage whose unique identification information matches the first identification information in the revocation request as the revocation stage to be executed.
[0196] In an optional implementation, the revocation module 308 is specifically used to: in the order of the revocation methods in the revocation executor list, pass the revocation information required for the corresponding revocation stage in the revocation information carrier into the revocation executor list one by one; and execute the revocation method corresponding to the corresponding revocation stage in the revocation executor list based on the passed revocation information.
[0197] In an optional implementation, the device for implementing the undo operation in the software system further includes a undo verification module.
[0198] The revocation verification module is used to obtain the revocation condition according to the business revocation rule in the software system; the revocation condition is the condition that needs to be met when executing the revocation request; the revocation request is verified based on the revocation condition; if the revocation request meets the revocation condition, the revocation verification passes; if the revocation request does not meet the revocation condition, the revocation verification fails.
[0199] The revocation verification module is also used to output abnormal information and intercept the revocation request after the revocation verification module fails to pass the verification, and the abnormal information includes the revocation condition that the revocation request does not meet.
[0200] In addition, an embodiment of the present application also provides a server for implementing an undo operation in a software system, wherein the server includes a processor and a memory.
[0201] The memory is used to store program code and transmit the program code to the processor;
[0202] The processor is used to execute the steps of the method for implementing the undo operation in the software system introduced in any manner of the above method embodiment according to the instructions in the program code.
[0203] In addition, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the program is executed by a processor, a method for implementing an undo operation in a software system as described in any of the method embodiments is implemented.
[0204] It should be noted that each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and server embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and server embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without paying creative labor.
[0205] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.< / t> < / t> < / t> < / discarddto> < / discarddto> < / discarddto> < / discarddto> < / t> < / t> < / t>
Claims
1. A method for implementing an undo operation in a software system, characterized in that: The method comprises: Receiving a cancellation request initiated by a user device through a software system; the cancellation request is used to indicate cancellation of a completed first business process; Based on the correspondence between the business process and the cancellation process, determining a first cancellation process corresponding to the first business process; Dividing the first revocation process into a plurality of independent revocation stages based on the service revocation rules in the software system, each revocation stage including a corresponding revocation method; Create and initialize the revocation information carrier and the revocation executor list; determining a revocation stage to be executed from the plurality of revocation stages; Obtaining the revocation information required for the revocation phase to be executed and adding it to the revocation information carrier; Adding the revocation method corresponding to the revocation stage to be executed to the revocation executor list; The revocation methods in the revocation executor list are executed based on the revocation information in the revocation information carrier.
2. The method according to claim 1, characterized in that The revocation information required in the revocation phase to be executed includes multiple types of revocation information; The step of creating and initializing a cancellation information carrier includes: Creating a revocation information carrier; The revocation information carrier is initialized through a builder pattern; the builder pattern supports the revocation information carrier to add multiple types of revocation information.
3. The method according to claim 1, characterized in that The revocation request includes first identification information, and the first identification information indicates a revocation stage to be executed; Each revocation stage also includes corresponding unique identification information, and the unique identification information is used to uniquely refer to the corresponding revocation stage.
4. The method according to claim 3, characterized in that The step of determining the revocation stage to be executed from the multiple revocation stages includes: Traversing the unique identification information of the multiple revocation stages; The revocation stage in which the unique identification information matches the first identification information in the revocation request is determined as the revocation stage to be executed.
5. The method according to claim 1, characterized in that The method of executing the revocation method in the revocation executor list based on the revocation information in the revocation information carrier includes: According to the order of the revocation methods in the revocation executor list, the revocation information required for the corresponding revocation stage in the revocation information carrier is transferred into the revocation executor list one by one; The undo method corresponding to the corresponding undo stage in the undo executor list is executed based on the incoming undo information.
6. The method according to any one of claims 1 to 5, characterized in that: After the receiving user equipment sends the initiated cancellation request through the software system, the method further includes: Obtaining a revocation condition according to the service revocation rule in the software system; the revocation condition is a condition that needs to be met when executing the revocation request; The revocation request is verified based on the revocation condition; if the revocation request meets the revocation condition, the revocation verification passes; if the revocation request does not meet the revocation condition, the revocation verification fails.
7. The method according to claim 6, characterized in that After the revocation check fails, the method further includes: Outputting exception information and intercepting the revocation request, the exception information including a revocation condition that the revocation request does not meet.
8. A device for implementing an undo operation in a software system, characterized in that: The device comprises: A receiving module, used to receive a cancellation request initiated by a user device through a software system; the cancellation request is used to indicate the cancellation of a completed first business process; A revocation process determination module, configured to determine a first revocation process corresponding to the first business process based on the correspondence between the business process and the revocation process; A revocation stage division module, used to divide the first revocation process into a plurality of independent revocation stages based on the business revocation rules in the software system, each revocation stage including a corresponding revocation method; A creation and initialization module, used for creating and initializing a revocation information carrier and a revocation executor list; A to-be-revoked stage determination module, used to determine a to-be-revoked stage from the multiple revocation stages; A first adding module, used for acquiring the revocation information required for the revocation phase to be executed and adding it to the revocation information carrier; A second adding module, used for adding the revocation method corresponding to the revocation stage to be executed to the revocation executor list; A revocation module is used to execute the revocation method in the revocation executor list based on the revocation information in the revocation information carrier.
9. A server for implementing an undo operation in a software system, characterized in that: The server comprises: a memory having a computer program stored thereon; A processor is used to execute the computer program in the memory to implement the steps of the method for implementing an undo operation in a software system according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for implementing an undo operation in a software system according to any one of claims 1 to 7 are implemented.