CN112766829A - Service processing method, device and equipment - Google Patents

Abstract

The embodiment of the specification provides a service processing method, a service processing device and service processing equipment. The method comprises the following steps: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; sequentially executing the sub-transactions in the target service according to the service execution flow; under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal; sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction. According to the method, the service is divided into different sub-transactions, so that when the service is abnormally executed, each sub-transaction can be sequentially compensated based on the execution condition of the sub-transaction, and the abnormal service is quickly and effectively processed.

Description

Service processing method, device and equipment

Technical Field

The embodiment of the specification relates to the technical field of big data, in particular to a service processing method, device and equipment.

Background

With the progress and development of society, the daily transactions that each company or organization needs to deal with are increasing. In order to accelerate the speed of transaction processing, a corresponding service processing template is generally designed and developed based on the execution process of daily services, so that a computer directly utilizes the service processing template to process the services to be processed, and the consumption of human resources is reduced.

When the pending service is executed, a service processing failure may occur. Even if the service fails to be processed, the data in the database may be changed accordingly during the execution process. To ensure correctness of service execution, it is generally necessary to roll back the data to ensure correctness of the data. However, at present, when a service is executed by using a service processing template, the boundary distinction of each step in the service is not clear. When the service execution is abnormal, the service is often rolled back as a whole because the specific state executed in the current state cannot be determined. Therefore, not only is the time or resources consumed when the abnormal service is processed increased, but also the data rollback error may occur, so that the abnormal service cannot be effectively processed. Therefore, there is a need for a method capable of executing a service normally and processing a service exception quickly and effectively when the service execution is abnormal.

Disclosure of Invention

An object of the embodiments of the present specification is to provide a method, an apparatus, and a device for processing a service, so as to solve a technical problem of how to quickly and efficiently process an abnormal service.

In order to solve the above technical problem, an embodiment of the present specification provides a service processing method, including: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; sequentially executing the sub-transactions in the target service according to the service execution flow; under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal; sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

A traffic processing apparatus, comprising: the target service acquisition module is used for acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; the sub-transaction execution module is used for sequentially executing the sub-transactions in the target service according to the service execution flow; the target sub-transaction determining module is used for determining the target sub-transaction executed when the target service is abnormal; the compensation method calling module is used for sequentially calling the compensation methods of all the sub-transactions reversely from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

A data migration apparatus comprising a memory and a processor, the memory for storing computer instructions; the processor, configured to execute the computer instructions to implement the following steps: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; sequentially executing the sub-transactions in the target service according to the service execution flow; under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal; sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

As can be seen from the technical solutions provided by the embodiments of the present specification, in the embodiments of the present specification, by dividing the target service into a plurality of independent sub-transactions and sequentially executing each sub-transaction based on the service execution flow, if a service execution exception occurs when executing the target service, the compensation method of each sub-transaction may be sequentially invoked from the target sub-transaction according to the sequence of the service execution flow to compensate according to the current execution condition of the sub-transaction, so that the data of the executed sub-transaction can be rolled back. In the case of compensation in the execution order of the sub-transactions, the accuracy of data rollback is ensured. In addition, for the sub-transactions which are not executed, a corresponding compensation method does not need to be called, so that the consumption of time and resources is reduced under the condition of ensuring normal processing. Therefore, the service processing method can quickly and effectively realize the processing of the abnormal service.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the specification, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a flowchart of a service processing method according to an embodiment of the present disclosure;

fig. 2 is a schematic diagram of a service processing method according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of a transaction submission process according to an embodiment of the present disclosure;

FIG. 4 is a flow chart of a business auditing process according to an embodiment of the present disclosure;

fig. 5 is a block diagram of a service processing apparatus according to an embodiment of the present disclosure;

fig. 6 is a block diagram of a service processing device according to an embodiment of the present disclosure.

Detailed Description

The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort shall fall within the protection scope of the present specification.

In order to solve the above technical problem, an embodiment of the present specification provides a service processing method. The execution main body of the service processing method is service processing equipment. The service processing equipment comprises but is not limited to a server, an industrial personal computer, a PC machine and the like. In some examples, the service processing method may be implemented based on java and SpringBoot frameworks, and of course, a specific implementation process of the service processing method in an actual application is not limited to the above examples. As shown in fig. 1, the service processing method may include the following specific implementation steps.

S110: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business.

The target traffic is the traffic that needs to be processed. Correspondingly, a corresponding service processing template can be preset in the device for processing the target service. The service processing template can process the target service by using a preset processing logic according to the type of the target service.

The target service may involve a change in the database in the course of being executed, so that when the target service fails to process, some of the executed steps in the target service may have changed the data in the database, although the service cannot be processed any more. In order to ensure the correctness of the data, when the data is rolled back, the data needing to be rolled back needs to be accurately determined.

In some embodiments, the target service may be a payment service. Since the payment service may involve alteration of account data of one or more users, in the event of failure of the payment service processing, if the processing is wrong, execution loss may be incurred to the benefit of the user. It is of particular importance to ensure that the payment service is executed correctly and efficiently.

The target service may include at least two sub-transactions. The sub-transactions may be specific steps in the service execution process, and different sub-transactions are respectively used for implementing different functions. In order to ensure the normal operation of the subsequent process, different sub-transactions are independent. Specifically, the sub-transactions may be composed of mutually independent codes, and execution of a certain sub-transaction does not affect changes of data corresponding to other sub-transactions, so that clear boundaries between steps are ensured, and the whole service can be effectively processed.

The sub-transactions are illustrated using a specific example. The sub-transactions can be seven sub-transactions of new application, new transaction, service submission, application auditing, service auditing and auditing approval. The seven sub-transactions are executed correspondingly in sequence, and after one sub-transaction is completed, the next sub-transaction is processed, for example, after a new transaction is added for the service, the service is added into a transaction table in the database. And the service submitting stage limits that only the services in the transaction table can be submitted, so that the independence between the services is ensured.

Specifically, the way of setting the service processing template including the sub-transaction may be to create an abstract class apptemplate for service processing, where the abstract class implements a submit method and an edit method, and respectively handles the submission and the audit processes, and defines initTrades, businessCheck, illegalCheck, beforessubmit, afterSubmit, beforeaudio and afteraudio methods for developers to rewrite specific service logic.

When the method is realized, a sub-transaction newly-added application AppSubmitBeginTask can be created to realize the interface ITask, the main content is to create a new service application, and the application state is the submission state. Creating a new transaction ApptTradeBeforePareTask realization interface ITask, wherein the main content is to create a new service transaction, and the transaction state is a ready state. Creating a sub-transaction application submission AppSubmitEndTask to realize an interface ITask, wherein the main content is to transfer the application flow to a state to be audited. And creating a sub-transaction application auditing AppDoBeginTask implementation interface ITask, wherein the main content is to transfer the application flow to an approval/rejection state. And creating a sub-transaction auditing agreement ApptTradeBeforeDoTask implementation interface ITask, wherein the main content is to transfer the transaction flow to a success/failure state.

Each task above has its own compensation method doCompensate as the compensation when an anomaly occurs.

The business execution flow may be used to represent the execution order of the sub-transactions in the target business. Under the condition that the sub-transactions are independent from each other, because there is generally no concurrent part between the sub-transactions, under the condition that the execution sequence of the sub-transactions is not defined additionally, the target business can not be processed according to the flow of business processing directly according to the execution logic of the sub-transactions. Therefore, the service execution flow needs to be set, so as to calibrate the execution sequence of the sub-transactions in the target service, and thus, the target service is effectively executed.

In some embodiments, the sub-transactions may include commit pre-processing, business commit, commit epilogue, audit pre-processing, business audit, audit epilogue, and the like. Correspondingly, when the target service is processed, the sub-transactions can be executed in sequence according to the service execution flows of preprocessing, service submission, submission ending, verification preprocessing, service verification and verification ending.

The above embodiment only schematically illustrates each sub-transaction, and in practical applications, other sub-transactions may also be set according to the requirements of the service or the service execution flow may be divided into different sub-transactions according to other manners, which is not described herein again.

S120: and sequentially executing the sub-transactions in the target service according to the service execution flow.

After the service execution flow and the corresponding sub-transaction of the target service are determined, the execution can be performed in sequence according to the service execution flow. For example, in the case that the target service includes sub-transactions of commit preprocessing, service commit, commit epilogue, audit preprocessing, service audit, and audit epilogue, the sub-transactions may be executed in sequence according to the order of the sub-transactions.

Using a specific example to explain, when implementing the service execution flow, an interface class ITask may be created first, where the interface class defines four methods, i.e., check, doTask, compensation, and doCompensate, which are a verification method, a logic processing method, whether a compensation method is needed, and a compensation method, for developers to rewrite specific logic. Creating a common business processing class, implementing the register method of the sub-transactions in the business processing class, sequentially executing the check method check and the logic processing method doTask of each sub-transaction according to the register sequence of the sub-transactions by a business processing chain, executing a compensation method once judging that the exception occurs according to whether the sub-transaction needs to be compensated, and calling the compensation method doCompensate of the sub-transaction according to the reverse order submitted by the sub-transaction.

In some embodiments, the execution process of the target service can be divided into a service submission part and a service auditing part according to different service processing scenarios. The service submitting part can perform preliminary audit on the data of the target service, and register the target service after the audit is passed, so that the registered service can be processed in the subsequent steps. The service auditing part can be an actual processing part of the service, the service auditing part can push the service to corresponding auditors, the service can be audited based on preset verification rules, and the two auditing modes can be combined to complete corresponding service auditing. And after the service is checked, the service is processed.

Specifically, for the service commit part, when the target service includes the sub-transactions of commit pre-processing, service commit and commit epilogue, as shown in fig. 3, the execution process may include the following specific steps.

S310: creating a service application corresponding to the target service; the service application is a submission status.

This step may correspond to committing this sub-transaction. When processing a target service, a corresponding application is generally required to be created for the target service, and then a corresponding part in a service processing template completes a service processing process in a subsequent process. And after the service application is created, the state of the service application is a submission state.

In some embodiments, after the service application is created, a transaction corresponding to the target service may also be created. The transaction may be the business execution flow. After analyzing the specific content of the target service, the target service may be divided into a plurality of sub-transactions based on a preset logic, and an execution sequence between each sub-transaction is determined as a service execution flow corresponding to the target service, so that the processing of the target service is completed in subsequent steps according to the service execution flow.

Specifically, during actual implementation, the logic of rewriting in the specific service inheritance class can be called by using the before service commit; and calling the rewritten validity check in the specific service inheritance class by utilizing the illegal check.

S320: verifying the target service based on a validity verification condition; the legality checking conditions comprise checking conditions aiming at whether the target service is empty, date format, data type, digit length, digit precision, mobile phone number format and identity card number format.

This step may correspond to the transaction committing this sub-transaction. Before processing the target service, firstly, validity check needs to be performed on the data of the target service. Some services whose own data do not meet the corresponding requirements may be filtered in advance in order to reduce the resources consumed by processing such services in the subsequent process.

Specifically, the legal verification condition may include a verification condition for whether the target service is null, a date format, a data type, a number length, a number precision, a mobile phone number format, or an identification number format. Whether the target service is empty or not can be used for judging whether the target service does not contain specific substantive content or not, so that the services are screened in advance. And the date format, the data type, the number length, the number precision, the mobile phone number format and the identity card number format can be preset with corresponding fixed judgment formats. The specific determination process may be set according to the requirements of the actual application, and is not described herein again.

Specifically, in actual implementation, the sub-transactions AppSubmitBeginTask, apptradebeforepreadetask, prepartask, appsubmittentask of a specific service may be sequentially invoked through a CommonBusiness service processing chain to execute the logical processing method dottask of each sub-transaction, and if an exception occurs, the compensation method of each task may be sequentially invoked in reverse order.

S330: submitting the target service to a corresponding service transaction table under the condition that the target service meets the validity check condition; the business transaction table is used for recording the business needing business processing.

This step may correspond to committing the child transaction ending. And under the condition that the target service meets the validity check condition, the target service can be submitted formally so as to realize the processing of the target service in the subsequent steps. Specifically, the target service may be registered in a service transaction table. The service transaction table is used for recording services needing service processing. When the sub-transaction in the subsequent step processes the target service, the corresponding service may be extracted from the service transaction table to perform the corresponding processing operation.

Correspondingly, under the condition that the target service is judged to meet the validity check condition, the service application can be pushed to a state to be checked, so as to indicate that the service can be checked in the subsequent steps.

Through the steps, the submission process of the target service is divided in a refining mode, so that different sub-transactions can execute corresponding operations independently, and accurate and effective execution of the service is guaranteed.

Specifically, the logic of rewriting in the specific service inheritance class can be called by using the afterSubmit in actual implementation.

In some embodiments, if the target service may not meet the validity check condition, the target sub-transaction that does not meet the validity check condition may be determined to wait for further investigation in the subsequent step, and accordingly, the efficiency of service check is also accelerated. Meanwhile, the state of the service application can be modified into a veto state to mark the service.

In some embodiments, for the service auditing section, when the target service includes auditing preprocessing, service auditing and auditing ending sub-transactions, as shown in fig. 4, the execution process may include the following specific steps.

S410: and pushing the target service to an auditing terminal.

This step may correspond to auditing preprocessing this sub-transaction. In the process of processing the service, service personnel may be further required to approve the service. Therefore, the target business can be pushed to the auditing terminal, and after the business personnel complete auditing the target business, subsequent processing can be carried out. The auditing standard of the specific service personnel can be set according to the actual situation, and is not limited herein.

The auditing terminal may be a terminal used by the service personnel. The auditing terminal can be a PC, a mobile terminal, intelligent wearable equipment and the like. The service personnel can receive the target service through the auditing terminal and also can input corresponding instructions through the auditing terminal to audit the target service.

Specifically, during actual implementation, the beforeAudit can be used for calling the rewritten logic in the specific service inheritance class; and calling the rewritten service logic check in the specific service inheritance class by using businessCheck.

S420: after receiving the auditing approval information fed back by the auditing terminal, auditing the target service by using a service logic verification rule; the service logic check rule is used for auditing the execution logic of the target service.

This step may correspond to the business reviewing this sub-transaction. And under the condition that the service personnel determines that the audited target service has no problem, corresponding audit approval information can be fed back to the service processing equipment through the audit terminal. The audit approval information is used for indicating that the service passes the audit, and the subsequent steps can be executed.

The business logic check rules may be rules formulated for the specific case of the business itself. For example, the business logic check rule may be a definition indicating that used pricing days cannot be deleted, or for a particular calculation formula, for example, "end-term net asset" equals "initial net asset + current net asset increase-current net asset decrease. In practical application, corresponding business logic check rules can be selected according to specific situations of business for auditing, and different target businesses can utilize different business logic check rules, so that the utilization of the target businesses is more consistent with practical situations.

Specifically, during actual implementation, the foregoing sub-transactions appdobeginntask, AppTradeBeforeDoTask and specific service DoTask may be sequentially invoked through a CommonBusiness service processing chain, the logical processing method DoTask of each sub-transaction is executed, and if an exception occurs, the compensation method of each task is sequentially invoked in a reverse order.

In some embodiments, after the business personnel audit the target business, audit rejection information can also be fed back. The audit veto information may be used to indicate that a service person has not audited the target service. Correspondingly, the state of the target service can be modified to be not approved when the audit rejection information is received. For the service with the status of not passing the audit, the service can not be processed any more, which indicates that the service is processed completely; or rolling back the data of the target service and re-executing the service to correctly complete the target service.

S430: under the condition that the target service accords with the logic verification rule, recording service data of the target service into a service formal table; and the service formal table is used for recording the processed services.

This step may correspond to auditing the epilogue of this sub-transaction. And under the condition that the target service conforms to the logic verification rule, the service is indicated to have no problem, and the service data of the target service can be recorded into a service formal table. When the service data is recorded into a service formal table, the process of adding or modifying the data in the database according to the target service is completed, thereby completing the target service. The corresponding business formal table can also be used for recording the processed business, and after the target business is recorded into the business formal table, the target business can be indicated to be processed normally.

Correspondingly, the state of the service application can be modified into an agreement state while the service is indicated to be processed normally.

Specifically, the af teraudit may be used to call the logic rewritten in the specific service inheritance class in actual implementation.

Through the steps, the service processing steps including auditing of the target service are divided in a refining mode, so that different sub-transactions can execute corresponding operations independently, and accurate and effective execution of the service is guaranteed.

It should be noted that, in the scenario addressed by the embodiment of the present disclosure, a case of service processing failure may be involved in the service processing process, so that executing each sub-transaction in sequence in this step does not completely refer to completing all sub-transactions, and only completing part of sub-transactions may occur, and then the subsequent steps S130 and S140 are executed in this case.

S130: and under the condition that the target service is abnormal in execution, determining the target sub-transaction executed when the target service is abnormal.

In the process of executing the target service, an abnormal execution condition may occur. If the target service is judged to be executed abnormally, the target service is executed in sequence according to the sub-transactions defined by the service execution flow, so that the target sub-transaction executed when the abnormality occurs can be determined. The target sub-transaction is a sub-transaction in which an execution exception occurs.

After the target sub-transaction is determined, the execution state of the target service can be determined, so that the data of the target service can be rolled back based on the target sub-transaction, and the accuracy of the data is ensured.

Correspondingly, when the service execution is abnormal, the state of the service application can be modified into a negative state, so that the service can be conveniently checked based on the state of the service.

S140: sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

After the target sub-transaction is determined, the sub-transactions that have been executed can be compensated in sequence. Specifically, each sub-transaction corresponds to a respective compensation method. The compensation method is used for rolling back the data changed by the corresponding sub-transaction, so that the data cannot be affected by the failed service under the condition that the target service execution fails.

Specifically, the implementation of the compensation method may be to obtain an operation record in a log, and sequentially rollback changed data according to a data change situation recorded in the operation record, thereby implementing compensation on each sub-transaction. The specific compensation method may be set according to an actual situation, and is not limited to the above example, and is not described herein again.

Fig. 2 is a schematic diagram of a processing manner in the case of abnormal execution of a target service. And under the condition that the service is normally executed, processing according to the sequence of the sub-transaction 1, the sub-transaction 2, the sub-transaction 3, the sub-transaction 4 and the sub-transaction 5, and finally normally finishing the target service. Accordingly, different sub-transactions correspond to respective compensation methods. In this example, assuming that the sub-transaction 4 is abnormal during the execution process, the sub-transactions 3, 2, and 1 have all completed execution at this time, and the compensation method 3, the compensation method 2, and the compensation method 1 may be sequentially executed to compensate the respective sub-transactions, thereby ensuring the accuracy of the data.

In this example, it is assumed that sub-transaction 4 does not alter data when it performs an exception, so compensation for each sub-transaction starts from compensation method 3; it may also happen that the compensation is performed in sequence starting from the compensation method 4. The specific compensation process may be set according to specific situations in practical applications, and is not limited to the above example, and is not described herein again.

It should be noted that the sub-transactions and the compensation method are connected in fig. 2 only for illustrating that there is a corresponding relationship between the two, and are not used to indicate a relationship of strong coupling between the two. In practical application, the two methods can be in a decoupling relation, and the compensation method is called only when needed.

Based on the description in step S110, in the case that the target service is a payment service, the compensation method of each sub-transaction corresponding to the compensation service may be to delete and/or call back service data modified by the payment service.

In some embodiments, when each sub-transaction is compensated by using the compensation method, the service processing operation of the corresponding sub-transaction may be obtained first. The business process operation may be a single specific operation, such as a function execution process or a value modification process.

After the service processing operation is obtained, whether the service processing operation involves the change of service data can be judged. The service data may be data involved in the actual execution of the target service, for example, when the target service is a payment service, the service data may be account data related to payment.

If the service processing operation involves changing the service data, the data changed by the service processing operation can be rolled back, so that the correctness of the data is ensured.

If the service processing operation does not involve the change of the service data, the data changed by the service processing operation can be marked without rolling back. Under the condition that the business processing operation does not involve the change of the business data, the changed data does not influence the normality of the business data, and the change conditions are kept, so that the specific condition of the abnormal condition can be better analyzed in the subsequent process, and the abnormal condition is favorably analyzed and solved.

The following description is provided with a specific example of a scenario for processing pending payment traffic in a professional annuity entrusted system. Firstly, a concrete service class PayApp is created to inherit an abstract class ApTemplete in the invention, and according to the process, only the following method needs to be rewritten: initTrades initiates transactions, registering two sub-transactions of the pending payment service: submitting PrepareTask by the pending payment service and auditing and approving DoTask by the pending payment service; the beforeesubmit fills the data of the application model and the pending payment model; carrying out legality verification on the payment data to be met by the illegal check; the afterSubmit sets the return prompt information; filling data of the application model by the beforeAudit; business logic verification is carried out on the payment data to be met by businessCheck; the afterAudio setting returns a prompt.

Then, a service processing class PayPrepareTask implementation interface ITask submitted by the pending payment service can be created, wherein the main content of the doTask is a transaction table for entering payment of the payment data, and the main content of the doCompensate is the transaction table data for deleting the transaction.

And finally, creating a service processing class PayDoTask realization interface ITask agreed by the audit of the payment service to be encountered, wherein the main content of the DoTask is the data of the transaction table to be paid and enters a formal table for payment, and the main content of the DoCompensate is the data of the formal table for deleting the transaction.

Based on the flow, clear boundary limitation can be performed on the execution flow of the service, so that the service is effectively processed under the condition of abnormal service execution, and the abnormal processing is guaranteed to be unified and regular.

Through the embodiment of the method and the introduction of the scenario example, it can be seen that in the method, the target service is divided into a plurality of independent sub-transactions, and each sub-transaction is sequentially executed based on the service execution flow, so that when the target service is executed, if the service execution is abnormal, the compensation method of each sub-transaction can be sequentially called from the target sub-transaction according to the sequence of the service execution flow to compensate according to the current execution condition of the sub-transaction, and the data of the executed sub-transaction can be rolled back. In the case of compensation in the execution order of the sub-transactions, the accuracy of data rollback is ensured. In addition, for the sub-transactions which are not executed, a corresponding compensation method does not need to be called, so that the consumption of time and resources is reduced under the condition of ensuring normal processing. Therefore, the service processing method can quickly and effectively realize the processing of the abnormal service.

Based on the service processing method, an embodiment of the present specification further provides a service processing apparatus. The service processing device may be disposed in the service processing device. As shown in fig. 5, the service processing apparatus may include the following modules.

A target service obtaining module 510, configured to obtain a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business.

And a sub-transaction executing module 520, configured to sequentially execute sub-transactions in the target service according to the service execution flow.

A target sub-transaction determining module 530, configured to determine, when the target service is abnormal in execution, a target sub-transaction executed when the target service is abnormal.

A compensation method calling module 540, configured to sequentially and reversely call a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

Based on the service processing method, an embodiment of the present specification further provides a service processing device. As shown in fig. 6, the traffic processing device may include a memory and a processor.

In this embodiment, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state disk, a U disk, or the like. The memory may be used to store computer program instructions.

In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth. The processor may execute the computer program instructions to perform the steps of: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; sequentially executing the sub-transactions in the target service according to the service execution flow; under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal; sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the present specification may be essentially or partially implemented in the form of software products, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The description is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.

Claims (12)

1. A method for processing a service, comprising:

acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business;

sequentially executing the sub-transactions in the target service according to the service execution flow;

under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal;

sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

2. The method of claim 1, wherein the target service comprises a payment service; correspondingly, the compensation method comprises deleting and/or calling back the service data modified by the payment service.

3. The method of claim 1, wherein the business execution flow comprises an execution flow of sub-transactions of commit pre-processing, business commit, commit epilogue, audit pre-processing, business audit, audit epilogue.

4. The method of claim 3, wherein the target transaction comprises a sub-transaction of commit pre-processing, transaction commit, commit epilogue; the sequentially executing the sub-transactions in the target service according to the service execution flow comprises the following steps:

creating a service application corresponding to the target service; the service application is in a submission state;

verifying the target service based on a validity verification condition; the legality checking conditions comprise checking conditions aiming at whether the target service is empty, date format, data type, digit length, digit precision, mobile phone number format and identity card number format;

submitting the target service to a corresponding service transaction table under the condition that the target service meets the validity check condition; the business transaction table is used for recording the business needing business processing;

and pushing the service application to a to-be-audited state.

5. The method of claim 4, wherein after verifying the target service based on a validity verification condition, further comprising:

under the condition that the target service does not accord with the legality checking condition, determining a target sub-transaction which does not accord with the legality checking condition;

and modifying the state of the service application into a rejection state.

6. The method of claim 3, wherein the target transaction includes sub-transactions of audit pre-processing, transaction audit, audit tail; the sequentially executing the sub-transactions in the target service according to the service execution flow comprises the following steps:

pushing the target service to an auditing terminal;

after receiving the auditing approval information fed back by the auditing terminal, auditing the target service by using a service logic verification rule; the service logic check rule is used for auditing the execution logic of the target service;

under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal;

and modifying the state of the service application into a rejection state.

7. The method of claim 6, wherein after the auditing the target service with the service logic check rule, further comprising:

and under the condition that the target service is normally executed, modifying the service application state into an agreement state.

8. The method of claim 1, wherein the method for sequentially calling the compensation of each sub-transaction in reverse from the target sub-transaction based on the business execution flow comprises:

acquiring the business processing operation of the sub-transaction;

and rolling back the data changed by the business processing operation under the condition that the business processing operation involves business data change.

9. The method of claim 8, wherein the obtaining the business processing operation of the sub-transaction is further followed by:

and marking the data changed by the business processing operation under the condition that the business processing operation does not involve business data change.

10. The method of claim 1, wherein the service processing method is implemented based on a SpringBoot framework.

11. A traffic processing apparatus, comprising:

the target service acquisition module is used for acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business;

the sub-transaction execution module is used for sequentially executing the sub-transactions in the target service according to the service execution flow;

the target sub-transaction determining module is used for determining the target sub-transaction executed when the target service is abnormal;

the compensation method calling module is used for sequentially calling the compensation methods of all the sub-transactions reversely from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

12. A traffic processing device comprising a memory and a processor;

the memory to store computer program instructions;

the processor to execute the computer program instructions to implement the steps of: acquiring a target service; the target service comprises at least two sub-transactions; the sub-transaction corresponds to a business execution flow of the target business; sequentially executing the sub-transactions in the target service according to the service execution flow; under the condition that the target service is abnormal in execution, determining a target sub-transaction executed when the target service is abnormal; sequentially and reversely calling a compensation method of each sub-transaction from the target sub-transaction based on the service execution flow; the sub-transactions respectively correspond to respective compensation methods; the compensation method is used for rolling back the data changed by the corresponding sub-transaction.

Images