Transaction processing method and apparatus

Abstract

Embodiments of the present application provide a transaction processing method and device, the method comprises: receiving a transaction processing request, wherein the transaction processing request contains a transaction type identifier of a target transaction; obtaining a transaction processing strategy corresponding to the transaction type identifier according to the transaction processing request, wherein the transaction processing strategy contains at least one sub-transaction, a transaction role corresponding to the sub-transaction, and a to-be-executed action corresponding to the transaction role; the transaction role corresponding to the sub-transaction is obtained from a pre-constructed role list; the to-be-executed action corresponding to the transaction role is obtained from a pre-constructed action list; and the to-be-executed action corresponding to the transaction role is executed to implement the target transaction. The present application improves the implementation efficiency and accuracy of the transaction.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a transaction processing method and apparatus. Background Technology

[0002] With the development of network technology, users' transaction needs are becoming increasingly complex and diverse.

[0003] In government affairs scenarios, different users may have different government affairs needs, and each user's needs may need to be realized by multiple personnel at different levels. Therefore, when designing business processes for government affairs scenarios, different roles need to be designed for personnel at each level, and the interaction between different roles is characterized by multiple process branches and no fixed execution order.

[0004] However, in existing technologies, transaction processes are generally designed manually by designers. Due to the large number of transaction processes and diverse roles in government scenarios, the design process is very complex and requires designers to build from scratch, which reduces the efficiency and effectiveness of transaction implementation. Summary of the Invention

[0005] This application provides a transaction processing method and apparatus to improve the efficiency of transaction processing.

[0006] In a first aspect, embodiments of this application provide a transaction processing method, including:

[0007] Receive a transaction processing request, wherein the transaction processing request contains a transaction type identifier of the target transaction;

[0008] The transaction processing strategy corresponding to the transaction type identifier is obtained according to the transaction processing request. The transaction processing strategy includes at least one sub-transaction, a transaction role corresponding to the sub-transaction, and an action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list.

[0009] Execute the pending actions corresponding to the transaction role to achieve the target transaction.

[0010] Optionally, each of the actions to be executed includes action conditions and action behaviors. Therefore, executing the action to be executed corresponding to the transaction role to achieve the target transaction includes:

[0011] Obtain the transaction status of the target transaction;

[0012] Determine the first target action to be executed corresponding to the first transaction role, wherein the transaction state satisfies the action conditions of the first target action to be executed;

[0013] Execute the actions contained in the first target action to be executed, and update the transaction status of the target transaction according to the execution result of the actions contained in the first target action to be executed, so as to realize the target transaction.

[0014] Optionally, updating the transaction state of the target transaction based on the execution result of the action behavior included in the first target action to be executed, in order to realize the target transaction, includes:

[0015] The transaction status of the target transaction is updated based on the execution result of the action behavior included in the first target action to be executed;

[0016] Determine the second target action to be executed corresponding to the second transaction role, wherein the updated transaction state of the target transaction satisfies the action condition of the second target action to be executed;

[0017] Execute the actions contained in the second target action to be executed, and update the transaction status of the target transaction based on the execution result of the actions contained in the second target action to be executed, so as to realize the target transaction.

[0018] Optionally, if the action behavior includes extended behavior and standard behavior, then the action behavior included in executing the first target action to be executed includes:

[0019] The extended behaviors and standard behaviors included in the first target action to be executed are verified;

[0020] After both the extended behavior and the standard behavior have passed the verification, the extended behavior and the standard behavior are executed.

[0021] Optionally, performing the extended behavior and the standard behavior includes:

[0022] The basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior are obtained by lazy loading.

[0023] The extended behavior and the standard behavior are executed based on the basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior.

[0024] The standard behavior includes at least one of creating a new sub-transaction, updating the current sub-transaction, updating transaction information, submitting for approval, and executing the approval.

[0025] Optionally, before receiving the transaction processing request, the method further includes:

[0026] The interaction relationships in the target transaction are parsed to obtain at least one sub-transaction;

[0027] Retrieve the transaction role corresponding to the at least one sub-transaction from the pre-built role list;

[0028] Retrieve the action to be executed corresponding to the transaction role from the pre-built action list;

[0029] Based on the at least one sub-transaction, the transaction role corresponding to the at least one sub-transaction, and the action to be executed corresponding to the transaction role, the transaction processing strategy corresponding to the target transaction is obtained.

[0030] Assign a transaction type identifier to the transaction processing strategy that corresponds to the target transaction.

[0031] Optionally, determining at least one transaction role corresponding to the target transaction includes:

[0032] Determine the attribute information of the transaction roles required for the target transaction, wherein the attribute information includes individuals and groups;

[0033] By determining whether the attribute information is an individual's transaction role or a group's transaction role, at least one transaction role corresponding to the target transaction is obtained.

[0034] Optionally, after executing the action to be executed corresponding to the transaction role to achieve the target transaction, the method further includes:

[0035] Obtain the sub-transaction to be added corresponding to the target transaction;

[0036] Determine whether the transaction role corresponding to the sub-transaction to be added exists in the role list;

[0037] If it does not exist, then create the transaction role corresponding to the sub-transaction to be added.

[0038] Optionally, the target transaction is a network management transaction, and the execution of the action to be executed corresponding to the transaction role to realize the target transaction includes:

[0039] The pending actions corresponding to different levels of transaction roles are executed to realize the network management transaction, wherein the pending actions include at least one of case filing, acceptance, feedback, reporting, application for extension, return, and receipt.

[0040] Secondly, embodiments of this application provide a transaction processing apparatus, including:

[0041] A receiving module is used to receive a transaction processing request, wherein the transaction processing request includes a transaction type identifier of the target transaction;

[0042] The processing module is configured to obtain a transaction processing strategy corresponding to the transaction type identifier according to the transaction processing request. The transaction processing strategy includes at least one sub-transaction, a transaction role corresponding to the sub-transaction, and an action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list.

[0043] The processing module is also used to execute the actions to be executed corresponding to the transaction role in order to realize the target transaction.

[0044] This application provides a transaction processing method and apparatus. Using the above scheme, a transaction processing request containing a transaction type identifier of the target transaction is first received. Then, a transaction processing strategy corresponding to the transaction type identifier is obtained according to the transaction processing request. Next, the sub-transactions included in the transaction processing strategy, the transaction roles corresponding to the sub-transactions, and the actions to be executed corresponding to the transaction roles are determined, and the actions to be executed are executed to achieve the target transaction. The transaction roles corresponding to the sub-transactions are obtained from a pre-built role list, and the actions to be executed corresponding to the transaction roles are obtained from a pre-built action list. By selecting the transaction roles corresponding to the sub-transactions from the pre-built role list and the actions to be executed corresponding to the transaction roles from the pre-built action list according to transaction requirements, the encapsulated transaction roles and their corresponding actions to be executed can be directly invoked, thereby obtaining the transaction process required for the government affairs scenario. This eliminates the need to build the transaction process from scratch, improving the flexibility and efficiency of implementing transaction processes in government affairs scenarios. Furthermore, the predefined transaction roles and actions to be executed are set according to the actual needs in real government affairs scenarios, making the final determined transaction process for the government affairs scenario more closely aligned with the actual scenario and improving the accuracy of the transaction process settings. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram illustrating the principle of transaction implementation in existing technologies;

[0047] Figure 2A schematic diagram of the application system architecture for the transaction processing method provided in the embodiments of this application;

[0048] Figure 3 A flowchart illustrating the transaction processing method provided in this application embodiment;

[0049] Figure 4 A schematic diagram illustrating the principle of the transaction implementation process based on a transaction state machine, provided for embodiments of this application;

[0050] Figure 5 A schematic diagram illustrating the principle of the transaction processing strategy generation process provided in this application embodiment;

[0051] Figure 6 This is a schematic diagram of the structure of the transaction processing apparatus provided in the embodiments of this application;

[0052] Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0054] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can also include other sequential examples besides those illustrated or described. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0055] Figure 1 This is a schematic diagram illustrating the principle of transaction implementation in existing technologies, such as... Figure 1As shown, in government service scenarios, different users may have different government service needs, and each user's needs may require multiple personnel at different levels to fulfill them. For example, a user may need to apply for a license, which requires review by multiple levels of personnel before a final decision is made on whether the application can be made, and may involve return processes, transfer processes, etc. Therefore, when designing transaction processes for government service scenarios, different roles need to be designed for personnel at each level, and the interaction relationships between different roles are characterized by multiple process branches and no fixed execution order for different transactions. At the same time, many reverse processes may also be involved, such as rollback review, delayed review, and step-by-step review, etc., and the differences between different transaction needs are significant, and the implementation processes are also very different. Therefore, for different transaction needs, designers need to manually design transaction processes and then implement users' transaction needs through the designed transaction processes. However, manually designing transaction processes by designers is very complex due to the large number of transaction processes and the diversity of roles in government service scenarios, and all processes need to be built from scratch, which reduces the efficiency and effectiveness of transaction implementation.

[0056] In addition, existing implementations can enumerate and arrange all processes involved in a transaction. However, this approach only supports a few pre-defined actions and does not support role-based arrangement, resulting in poor flexibility and insufficient adaptability to complex transaction flow scenarios.

[0057] Based on the aforementioned technical issues, this application addresses the problem by selecting transaction roles corresponding to sub-transactions from a pre-built role list and actions to be executed corresponding to transaction roles from a pre-built action list. This allows for the direct invocation of encapsulated transaction roles and their corresponding actions to be executed, thereby obtaining the transaction flow required for government scenarios. This eliminates the need to build transaction flows from scratch, improving the flexibility and efficiency of implementing government scenario transaction flows. Furthermore, the predefined transaction roles and actions to be executed are set according to the actual needs in real government scenarios, making the final determined government scenario transaction flow more closely aligned with the actual scenario and improving the accuracy of transaction flow settings.

[0058] Figure 2 This is a schematic diagram of the application system architecture for the transaction processing method provided in the embodiments of this application, such as... Figure 2As shown, the application system may include: a client 201, a server 202, and a database 203. There may be multiple clients 201, each of which can send a transaction processing request to the server 202. After receiving the transaction processing request, the server 202 can retrieve the transaction processing strategy corresponding to the transaction type identifier from the database 203 based on the transaction type identifier of the target transaction contained in the transaction processing request, and implement the target transaction according to the transaction processing strategy. Furthermore, after implementing the target transaction, the server can send a target transaction implementation prompt to the corresponding client 201.

[0059] Database 203 can be a local database deployed on server 202 or a cloud database. Client 201 can be a device capable of generating and sending transaction processing requests, such as a mobile phone, personal computer, tablet, or smart wearable device.

[0060] In addition, the application system may not include a client 201. That is, the transaction processing request can be generated locally on the server 202, and the transaction processing strategy corresponding to the transaction type identifier can be obtained from the database 203 according to the transaction type identifier contained in the transaction processing request, and the target transaction can be implemented according to the transaction processing strategy.

[0061] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0062] Figure 3 This is a flowchart illustrating a transaction processing method provided in an embodiment of this application. The method in this embodiment can be executed by server 202. Figure 3 As shown, the method in this embodiment may include:

[0063] S301: Receive a transaction processing request, wherein the transaction processing request contains the transaction type identifier of the target transaction.

[0064] In this embodiment, when a target transaction needs to be implemented, a transaction processing request containing a transaction type identifier of the target transaction can be generated first. The target transaction corresponds one-to-one with the transaction type identifier, and the style of the transaction type identifier can be customized. For example, it can contain any one or more of lowercase letters, uppercase letters, Arabic numerals, and special characters.

[0065] The target transaction can be of different types. For example, it can be a landscaping transaction or an urban planning transaction. Further details will not be provided here.

[0066] Furthermore, there are multiple ways to generate transaction processing requests. For example, in one implementation, a transaction processing request can be generated at preset intervals; in another implementation, a transaction processing request can be generated based on the user's touch operation.

[0067] S302: Obtain the transaction processing strategy corresponding to the transaction type identifier according to the transaction processing request. The transaction processing strategy includes at least one sub-transaction, the transaction role corresponding to the sub-transaction, and the action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list.

[0068] In this embodiment, each transaction has its corresponding transaction processing strategy. After receiving a transaction processing request, the transaction processing strategy corresponding to the transaction type identifier can be obtained according to the transaction processing request.

[0069] The transaction processing strategy represents the specific implementation method of the target transaction. After the target transaction is determined, a corresponding transaction processing strategy can be generated for the target transaction, and the target transaction can be associated with the transaction processing strategy through the transaction type identifier.

[0070] Furthermore, a transaction processing strategy includes at least one sub-transaction, a corresponding transaction role for the sub-transaction, and actions to be executed for each transaction role. The interactions between transaction roles constitute the entire transaction flow, and these interactions can be mediated by sub-transactions. Two roles with an interaction relationship act as the initiator and receiver of the sub-transaction, respectively. The actions that the initiator takes to initiate a sub-transaction, and the actions that the initiator can perform on the initiated sub-transaction, can be specified. Similarly, the actions that the receiver can perform after receiving a sub-transaction can also be specified.

[0071] S303: Execute the action to be performed corresponding to the transaction role in order to achieve the target transaction.

[0072] In this embodiment, after determining the action to be executed corresponding to each transaction role, the action to be executed contained in the sub-transaction can be executed to achieve the target transaction.

[0073] Furthermore, each of the actions to be executed includes action conditions and action behaviors. Specifically, executing the action corresponding to the transaction role to achieve the target transaction may include:

[0074] Obtain the transaction status of the target transaction.

[0075] Determine the first target action to be executed corresponding to the first transaction role, wherein the transaction state satisfies the action conditions of the first target action to be executed.

[0076] Execute the actions contained in the first target action to be executed, and update the transaction status of the target transaction according to the execution result of the actions contained in the first target action to be executed, so as to realize the target transaction.

[0077] Specifically, an action to be executed can include action conditions and action behaviors. Action conditions can specify multiple transaction states and event states, indicating that the action behaviors within that action can only be executed under the specified transaction and event states. For example, action conditions can include pending dispatch, pending signature, pending processing, pending review, rolled back, completed, and cancelled. Furthermore, the completion of an action can be used to dispatch different types of transactions to other roles or to update information about its own transactions and events.

[0078] Furthermore, for the process of updating information about its own transactions and events through the execution of actions, a solution can be implemented for situations where a transaction involves only one transaction role and there is no interaction between transaction roles. Specifically, the initial transaction state of the target transaction can be obtained first. Then, based on the initial transaction state, the action conditions that must be met can be determined. The action to be executed corresponding to these conditions is the first target action to be executed, and the transaction role corresponding to this first target action to be executed is the first transaction role. In other words, the first target action to be executed can be determined from the state of the target transaction. Then, the actions contained in this first target action to be executed can be performed, and the transaction state of the target transaction can be updated based on the execution result of these actions to achieve the target transaction.

[0079] Furthermore, for the process of dispatching different types of tasks to other roles through the execution of actions, this can be applied to situations where multiple task roles are involved and interactions between them are required. Correspondingly, updating the transaction state of the target transaction based on the execution result of the actions contained in the first target task to be executed, in order to realize the target transaction, can specifically include:

[0080] The transaction status of the target transaction is updated based on the execution result of the action behavior contained in the first target action to be executed.

[0081] Determine the second target action to be executed corresponding to the second transaction role, wherein the updated transaction state of the target transaction satisfies the action conditions of the second target action to be executed.

[0082] Execute the actions contained in the second target action to be executed, and update the transaction status of the target transaction based on the execution result of the actions contained in the second target action to be executed, so as to realize the target transaction.

[0083] Specifically, after updating the state of the target transaction based on the execution results of the actions contained in the first target action to be executed, the second target action to be executed corresponding to the second transaction role can be determined based on the updated transaction state of the target transaction. The second transaction role is different from the first transaction role, and the updated transaction state of the target transaction satisfies the action conditions of the second target action to be executed. Then, the actions contained in the second target action to be executed can be executed, and the transaction state of the target transaction can be updated again based on the execution results of the actions contained in the second target action to be executed, until the target transaction is achieved.

[0084] In summary, by using role-oriented action choreography, different numbers of roles can be set according to the needs of a transaction, thereby meeting the actual requirements of the transaction and improving the flexibility of the transaction implementation process.

[0085] Furthermore, since the action behavior includes extended behavior and standard behavior, the action behavior included in executing the first target action to be executed may specifically include:

[0086] The extended behaviors and standard behaviors included in the first target action to be executed are verified.

[0087] After both the extended behavior and the standard behavior have passed the verification, the extended behavior and the standard behavior are executed.

[0088] Specifically, actions can be categorized into two types: standard actions, which are general and applicable to different transactions; and extended actions, which are non-general and custom-defined based on the actual needs of the target transaction. When executing actions included in the first target action, the extended and standard actions can be validated first. Only after both extended and standard actions have passed validation can they be executed. Extended actions can be implemented using SPI (Service Provider Interface).

[0089] In addition, the other actions to be performed are similar to those of the first objective, and will not be specifically restricted here.

[0090] Furthermore, the execution of the extended behavior and the standard behavior may specifically include:

[0091] The basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior are obtained through lazy loading.

[0092] The extended behavior and the standard behavior are executed based on the basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior.

[0093] The standard behavior includes at least one of creating a new sub-transaction, updating the current sub-transaction, updating transaction information, submitting for approval, and executing the approval.

[0094] Specifically, the basic data corresponding to extended behaviors and standard behaviors is obtained on demand through lazy loading. Then, the extended behaviors and standard behaviors are executed based on the basic data corresponding to the extended behaviors (such as request information, sub-transaction information, personnel information, etc.) and the basic data corresponding to the standard behaviors. The processing results of the basic data requested through lazy loading can be reused in multiple behaviors, reducing the number of times data is obtained and thus improving the processing efficiency of actions.

[0095] For example, Figure 4 A schematic diagram illustrating the principle of the transaction implementation process based on a transaction state machine provided in this application embodiment, as shown below. Figure 4 As shown, in this embodiment, after a transaction processing strategy corresponding to the transaction type identifier is initiated through a transaction processing request, the first action can be automatically executed according to the transaction flow arranged in the transaction processing strategy, dispatching a sub-transaction to the first transaction role. After receiving the sub-transaction, the transaction role can obtain a list of executable actions on the sub-transaction and select one to execute as needed. Through the completion of action execution, different types of transactions are dispatched to other roles, or the information of its own transactions and events is updated. Each transaction implicitly maintains a transaction state machine. After an action is executed, the transaction state of the transaction state machine changes, thereby determining the next executable action. When executing a transaction action, all actions of that transaction action can be constructed into an execution chain according to a rule sequence. The action execution process is implemented in a manner similar to two-phase commit. Actions can include standard actions and extended actions. Before executing an action, it can be validated, and only after the validation is passed can the action be executed. When calibrating an action, extended actions can be validated first, or standard actions can be validated first. Correspondingly, when executing an action, extended actions can be executed first, or standard actions can be executed first. Furthermore, before validating the action behavior, the action conditions can be validated first. Only after the action conditions pass the validation can the standard behavior and extended behavior be validated. In this embodiment, the extended behavior can be pre-validated first, and then the standard behavior can be parameter-validated. When all validations pass, the standard behavior and extended behavior of the action are executed sequentially, and finally the behavior execution result is returned.

[0096] In summary, by integrating transaction states, action triggering conditions, and action behaviors to realize the operation of the transaction state machine, forward and reverse transaction processes can be flexibly implemented to meet the complex flow requirements of transactions.

[0097] The methods for performing pre-validation on extended behaviors and parameter validation on standard behaviors can be implemented using existing methods.

[0098] After adopting the above scheme, a transaction processing request containing a transaction type identifier of the target transaction can be received first. Then, the transaction processing strategy corresponding to the transaction type identifier can be obtained according to the transaction processing request. Next, the sub-transactions, transaction roles corresponding to the sub-transactions, and pending actions corresponding to the transaction roles in the transaction processing strategy can be determined, and the pending actions can be executed to realize the target transaction. Among them, the transaction roles corresponding to the sub-transactions are obtained from a pre-built role list, and the pending actions corresponding to the transaction roles are obtained from a pre-built action list. By selecting the transaction roles corresponding to the sub-transactions from the pre-built role list and the pending actions corresponding to the transaction roles from the pre-built action list according to the transaction requirements, the encapsulated transaction roles and the pending actions corresponding to the transaction roles can be directly invoked, thereby obtaining the transaction process required for the government affairs scenario. There is no need to build the transaction process from scratch, which improves the flexibility and efficiency of implementing the transaction process in the government affairs scenario. Moreover, the predefined transaction roles and pending actions are set according to the actual needs in the actual government affairs scenario, making the final determined transaction process of the government affairs scenario more in line with the actual scenario and improving the accuracy of the transaction process setting.

[0099] based on Figure 3 In addition to the method described herein, this specification also provides some specific implementation schemes of the method, which will be described below.

[0100] Furthermore, in another embodiment, before receiving the transaction processing request, the method may further include:

[0101] The interaction relationships in the target transaction are parsed to obtain at least one sub-transaction.

[0102] Retrieve the transaction role corresponding to the at least one sub-transaction from the pre-built role list.

[0103] Retrieve the action to be executed corresponding to the transaction role from the pre-built action list.

[0104] Based on the at least one sub-transaction, the transaction role corresponding to the at least one sub-transaction, and the action to be executed corresponding to the transaction role, the transaction processing strategy corresponding to the target transaction is obtained.

[0105] Assign a transaction type identifier to the transaction processing strategy that corresponds to the target transaction.

[0106] In this embodiment, when establishing the transaction processing strategy for the target transaction, the interaction relationships of the target transaction can be parsed first to determine the sub-transactions contained in the target transaction, the transaction roles implementing each sub-transaction, and the actions to be executed for each transaction role, thereby obtaining the transaction processing strategy corresponding to the target transaction. The actions to be executed include action conditions and action behaviors. The action behaviors in the actions to be executed can only be executed when the transaction state of the target transaction meets the action conditions.

[0107] In addition, after obtaining the transaction processing strategy corresponding to the target transaction, in order to improve the convenience of obtaining subsequent transaction processing strategies, a transaction type identifier corresponding to the target transaction can be assigned to the transaction processing strategy. That is, the transaction processing strategy corresponding to the target transaction can be directly obtained based on the transaction identifier type.

[0108] For example, Figure 5 This is a schematic diagram illustrating the principle of the transaction processing strategy generation process provided in the embodiments of this application, such as... Figure 5 As shown in this embodiment, the transaction status can include pending dispatch, pending receipt, pending processing, pending review, rolled back, completed, and cancelled. The actions to be executed can include action conditions and action behaviors. Action conditions can be divided into two dimensions: event status (e.g., pending processing, rolled back) and transaction status (e.g., pending dispatch, pending receipt). Action behaviors can include standard behaviors and extended behaviors. Transaction roles can include two types of transaction roles: individual and group. The transaction processing strategy corresponding to the target transaction can be obtained through the transaction status, actions to be executed, and transaction roles.

[0109] Furthermore, determining at least one transaction role corresponding to the target transaction may specifically include:

[0110] Determine the attribute information of the transaction roles required for the target transaction, wherein the attribute information includes individuals and groups.

[0111] The transaction role corresponding to the target transaction is obtained by determining whether the attribute information is an individual's transaction role or a group's transaction role.

[0112] Specifically, the attribute information of a transaction role can be of various types, representing different transaction role types. For example, the attribute information of a transaction role can be that of an individual or a group. The attribute information of the transaction roles required for the target transaction can be determined first, and then the specific transaction roles with different attribute information can be determined separately, thus obtaining the transaction roles corresponding to the target transaction.

[0113] Optionally, transaction roles with attribute information of an individual and transaction roles with attribute information of a group can be determined to obtain the transaction role corresponding to the target transaction. Transaction roles can be one or more, or only transaction roles with attribute information of an individual or only transaction roles with attribute information of a group can be determined.

[0114] Furthermore, determining that the attribute information is an individual's transaction role can specifically include:

[0115] Determine the attribute information corresponding to the personal tag from the list of transaction roles to define the personal transaction role.

[0116] Specifically, for transaction roles with individual attribute information, pre-defined roles can be stored in a transaction role list, with each transaction role in the list having its corresponding tag (which can be an attribute plus a role name). Then, the corresponding attribute information for an individual can be determined from the transaction role list based on the individual tag. Different groups may involve transaction roles corresponding to individual tags, and this method can be used to retrieve all transaction roles corresponding to individual tags in different departments from the transaction role list.

[0117] Furthermore, the principle is similar for transaction roles whose attribute information is a group. The group tag can be a keyword of the same group at different levels. Through the group tag, all transaction roles at different levels corresponding to the group tag can be obtained.

[0118] Alternatively, you can manually select from the list of transaction roles either the individual role or the group role, which corresponds to the target transaction.

[0119] In summary, by setting different attribute transaction roles, the flexibility of transaction role settings is improved. Furthermore, by arranging transactions by role, the requirement to arrange and combine branches in all transactions is avoided. It also makes it easy to add new actions to roles, thereby improving the flexibility of subsequent transaction adjustments.

[0120] Furthermore, in another embodiment, after executing the action to be executed corresponding to the transaction role to achieve the target transaction, the method further includes:

[0121] Obtain the sub-transaction to be added corresponding to the target transaction.

[0122] Determine whether the transaction role corresponding to the sub-transaction to be added exists in the role list.

[0123] If it does not exist, then create the transaction role corresponding to the sub-transaction to be added.

[0124] In this embodiment, the implementation of the target transaction may involve adjustments to the transaction, such as adding or deleting sub-transactions.

[0125] Optionally, in scenarios where sub-transactions need to be added, the sub-transactions to be added corresponding to the target transaction can be obtained first. Then, it can be determined whether a transaction role corresponding to the sub-transaction to be added exists in the role list. If it already exists, the sub-transaction to be added can be directly added to the sub-transaction list of the transaction role. If it does not exist, a transaction role corresponding to the sub-transaction to be added can be created, and the sub-transaction to be added can be added to the sub-transaction list of the newly created transaction role.

[0126] Furthermore, in another embodiment, the target transaction is a network management transaction, and the execution of the action to be performed corresponding to the transaction role to realize the target transaction may specifically include:

[0127] The pending actions corresponding to different levels of transaction roles are executed to realize the network management transaction, wherein the pending actions include at least one of case filing, acceptance, feedback, reporting, application for extension, return, and receipt.

[0128] In this embodiment, the target transaction can be a network management transaction, i.e., managing network services in the area. The designer can divide the area into different levels, and then further divide the network management transaction into sub-transactions at different levels. For example, the area can be divided into city, county, town, and village levels, meaning the network management transaction can be divided into city-level, county-level, town-level, and village-level sub-transactions. Different sub-transactions correspond to different transaction roles. The transaction role corresponding to the city-level sub-transaction (city-level network management center), the county-level sub-transaction (county-level network management center), the town-level sub-transaction (town-level network management center), and the village-level sub-transaction (village-level network management center) can be selected from a pre-built list of transaction roles. Then, actions to be executed (such as case filing, acceptance, feedback, reporting, application for extension, return, and receipt) are selected from the pre-built action list corresponding to each transaction role to obtain the transaction processing strategy corresponding to the network management transaction. Finally, a transaction type identifier corresponding to the network management transaction is assigned to this transaction processing strategy.

[0129] Upon receiving a transaction processing request, the executor can obtain the transaction processing strategy corresponding to the network management transaction based on the transaction type identifier contained in the request. Then, it can obtain the city-level, county-level, town-level, and village-level sub-transactions within the transaction processing strategy. Next, it determines the different transaction roles corresponding to different sub-transactions and the actions to be executed for each transaction role. Finally, it executes the actions to be executed corresponding to the transaction role based on the transaction status to realize the network management transaction.

[0130] The designer and the implementer can be located on the same server or on different servers.

[0131] Based on the same idea, this specification also provides an apparatus corresponding to the above method. Figure 6 This is a schematic diagram of the structure of the transaction processing apparatus provided in the embodiments of this application, such as... Figure 6 As shown, the apparatus provided in this embodiment may include:

[0132] The receiving module 601 is used to receive a transaction processing request, wherein the transaction processing request includes a transaction type identifier of the target transaction.

[0133] The processing module 602 is configured to obtain a transaction processing strategy corresponding to the transaction type identifier according to the transaction processing request. The transaction processing strategy includes at least one sub-transaction, a transaction role corresponding to the sub-transaction, and an action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list.

[0134] The processing module 602 is also used to execute the action to be executed corresponding to the transaction role in order to realize the target transaction.

[0135] In this embodiment, each of the actions to be executed includes action conditions and action behaviors. The processing module 602 is further configured to:

[0136] Obtain the transaction status of the target transaction.

[0137] A first transaction role is determined to correspond to a first target action to be executed, wherein the transaction state satisfies the action conditions of the first target action to be executed.

[0138] Execute the actions contained in the first target action to be executed, and update the transaction status of the target transaction according to the execution result of the actions contained in the first target action to be executed, so as to realize the target transaction.

[0139] Furthermore, the processing module 602 is also used for:

[0140] The transaction status of the target transaction is updated based on the execution result of the action behavior contained in the first target action to be executed.

[0141] Determine the second target action to be executed corresponding to the second transaction role, wherein the updated transaction state of the target transaction satisfies the action conditions of the second target action to be executed.

[0142] Execute the actions contained in the second target action to be executed, and update the transaction status of the target transaction based on the execution result of the actions contained in the second target action to be executed, so as to realize the target transaction.

[0143] Furthermore, the action behavior includes extended behavior and standard behavior, and the processing module 602 is also used for:

[0144] The extended behaviors and standard behaviors included in the first target action to be executed are verified.

[0145] After both the extended behavior and the standard behavior have passed the verification, the extended behavior and the standard behavior are executed.

[0146] Furthermore, the processing module 602 is also used for:

[0147] The basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior are obtained through lazy loading.

[0148] The extended behavior and the standard behavior are executed based on the basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior.

[0149] The standard behavior includes at least one of creating a new sub-transaction, updating the current sub-transaction, updating transaction information, submitting for approval, and executing the approval.

[0150] In another embodiment, the processing module 602 is further configured to:

[0151] Retrieve the transaction role corresponding to the at least one sub-transaction from the pre-built role list.

[0152] Retrieve the action to be executed corresponding to the transaction role from the pre-built action list.

[0153] Based on the at least one sub-transaction, the transaction role corresponding to the at least one sub-transaction, and the action to be executed corresponding to the transaction role, the transaction processing strategy corresponding to the target transaction is obtained.

[0154] Assign a transaction type identifier to the transaction processing strategy that corresponds to the target transaction.

[0155] Furthermore, the processing module 602 is also used for:

[0156] Determine the attribute information of the transaction roles required for the target transaction, wherein the attribute information includes individuals and groups.

[0157] The transaction role corresponding to the target transaction is obtained by determining whether the attribute information is an individual's transaction role or a group's transaction role.

[0158] Furthermore, the processing module 602 is also used for:

[0159] Determine the attribute information corresponding to the personal tag from the list of transaction roles to define the personal transaction role.

[0160] In another embodiment, the processing module 602 is further configured to, after executing the actions to be executed contained in the sub-transaction corresponding to the at least one transaction role to achieve the target transaction, include:

[0161] Obtain the sub-transaction to be added corresponding to the target transaction.

[0162] Determine whether the transaction role corresponding to the sub-transaction to be added exists in the role list.

[0163] If it does not exist, then create the transaction role corresponding to the sub-transaction to be added.

[0164] In another embodiment, the target transaction is a network management transaction, and the processing module 602 is further configured to:

[0165] The pending actions corresponding to different levels of transaction roles are executed to realize the network management transaction, wherein the pending actions include at least one of case filing, acceptance, feedback, reporting, application for extension, return, and receipt.

[0166] The apparatus provided in this application embodiment can achieve the above-mentioned... Figure 2 The methods in the embodiments shown are similar in principle and technical effect, and will not be described again here.

[0167] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 7 As shown, the device 700 provided in this embodiment includes a processor 701 and a memory communicatively connected to the processor. The processor 701 and the memory 702 are connected via a bus 703.

[0168] In a specific implementation, the processor 701 executes the computer execution instructions stored in the memory 702, causing the processor 701 to execute the method in the above method embodiment.

[0169] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0170] In the above Figure 7In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0171] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0172] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0173] This application also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the transaction processing method described in the above method embodiments.

[0174] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the transaction processing method described above.

[0175] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0176] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0177] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A transaction processing method, characterized in that, include: Receive a transaction processing request, wherein the transaction processing request contains a transaction type identifier of the target transaction, and the transaction type identifier is used to identify the type of the target transaction; The transaction processing strategy corresponding to the transaction type identifier is obtained according to the transaction processing request. The transaction processing strategy includes at least one sub-transaction, a transaction role corresponding to the sub-transaction, and an action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list. The interaction relationship between the transaction roles corresponding to each sub-transaction constitutes the entire transaction process. Two roles with an interaction relationship are respectively the initiator and receiver of the sub-transaction, and the action to be executed is specified according to the interaction relationship. Each action to be executed includes action conditions and action behavior. Obtain the transaction status of the target transaction; Determine the first target action to be executed corresponding to the first transaction role, wherein the transaction state satisfies the action conditions of the first target action to be executed; Execute the actions contained in the first target action to be executed, and update the transaction status of the target transaction according to the execution result of the actions contained in the first target action to be executed, so as to realize the target transaction.

2. The method according to claim 1, characterized in that, The step of updating the transaction state of the target transaction based on the execution result of the action behavior included in the first target action to be executed, in order to realize the target transaction, includes: The transaction status of the target transaction is updated based on the execution result of the action behavior included in the first target action to be executed; Determine the second target action to be executed corresponding to the second transaction role, wherein the updated transaction state of the target transaction satisfies the action condition of the second target action to be executed; Execute the actions contained in the second target action to be executed, and update the transaction status of the target transaction based on the execution result of the actions contained in the second target action to be executed, so as to realize the target transaction.

3. The method according to claim 1, characterized in that, The action behavior includes extended behavior and standard behavior. Therefore, the action behavior included in executing the first target action to be executed includes: The extended behaviors and standard behaviors included in the first target action to be executed are verified; After both the extended behavior and the standard behavior have passed the verification, the extended behavior and the standard behavior are executed.

4. The method according to claim 3, characterized in that, The execution of the extended behavior and the standard behavior includes: The basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior are obtained by lazy loading. The extended behavior and the standard behavior are executed based on the basic data corresponding to the extended behavior and the basic data corresponding to the standard behavior. The standard behavior includes at least one of creating a new sub-transaction, updating the current sub-transaction, updating transaction information, submitting for approval, and executing the approval.

5. The method according to any one of claims 1-4, characterized in that, Before receiving the transaction processing request, the method further includes: The interaction relationships in the target transaction are parsed to obtain at least one sub-transaction; Retrieve the transaction role corresponding to the at least one sub-transaction from the pre-built role list; Retrieve the action to be executed corresponding to the transaction role from the pre-built action list; Based on the at least one sub-transaction, the transaction role corresponding to the at least one sub-transaction, and the action to be executed corresponding to the transaction role, the transaction processing strategy corresponding to the target transaction is obtained. Assign a transaction type identifier to the transaction processing strategy that corresponds to the target transaction.

6. The method according to claim 5, characterized in that, Determining the transaction role corresponding to the target transaction includes: Determine the attribute information of the transaction roles required for the target transaction, wherein the attribute information includes individuals and groups; The transaction role corresponding to the target transaction is obtained by determining whether the attribute information is an individual's transaction role or a group's transaction role.

7. The method according to any one of claims 1-4, characterized in that, After executing the pending actions corresponding to the transaction role to achieve the target transaction, the process further includes: Obtain the sub-transaction to be added corresponding to the target transaction; Determine whether the transaction role corresponding to the sub-transaction to be added exists in the role list; If it does not exist, then create the transaction role corresponding to the sub-transaction to be added.

8. The method according to any one of claims 1-4, characterized in that, The target transaction is a network management transaction. The execution of the actions to be performed corresponding to the transaction role to achieve the target transaction includes: The pending actions corresponding to different levels of transaction roles are executed to realize the network management transaction, wherein the pending actions include at least one of case filing, acceptance, feedback, reporting, application for extension, return, and receipt.

9. A transaction processing apparatus, characterized in that, include: A receiving module is configured to receive a transaction processing request, wherein the transaction processing request includes a transaction type identifier of the target transaction, and the transaction type identifier is used to identify the type of the target transaction; The processing module is configured to obtain a transaction processing strategy corresponding to the transaction type identifier based on the transaction processing request. The transaction processing strategy includes at least one sub-transaction, a transaction role corresponding to the sub-transaction, and an action to be executed corresponding to the transaction role. The transaction role corresponding to the sub-transaction is obtained from a pre-built role list, and the action to be executed corresponding to the transaction role is obtained from a pre-built action list. The interaction relationships between the transaction roles corresponding to each sub-transaction constitute the entire transaction flow. Two roles with an interaction relationship serve as the initiator and receiver of the sub-transaction, respectively, and the action to be executed is specified according to the interaction relationship. Each action to be executed includes action conditions and action behavior. The processing module is also used to obtain the transaction status of the target transaction; Determine the first target action to be executed corresponding to the first transaction role, wherein the transaction state satisfies the action conditions of the first target action to be executed; Execute the actions contained in the first target action to be executed, and update the transaction status of the target transaction according to the execution result of the actions contained in the first target action to be executed, so as to realize the target transaction.

Images