CN113626209A - State machine-based event-driven method and system applied to transaction field - Google Patents
State machine-based event-driven method and system applied to transaction field Download PDFInfo
- Publication number
- CN113626209A CN113626209A CN202110697789.0A CN202110697789A CN113626209A CN 113626209 A CN113626209 A CN 113626209A CN 202110697789 A CN202110697789 A CN 202110697789A CN 113626209 A CN113626209 A CN 113626209A
- Authority
- CN
- China
- Prior art keywords
- transaction
- module
- state
- event
- instance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 74
- 238000012545 processing Methods 0.000 claims abstract description 27
- 230000008569 process Effects 0.000 claims description 18
- 230000002688 persistence Effects 0.000 claims description 14
- 238000012790 confirmation Methods 0.000 claims description 9
- 238000010586 diagram Methods 0.000 description 15
- 238000013461 design Methods 0.000 description 14
- 230000008859 change Effects 0.000 description 12
- 230000032683 aging Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000013178 mathematical model Methods 0.000 description 2
- 238000004886 process control Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/4493—Object persistence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4498—Finite state machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
- G06F9/548—Object oriented; Remote method invocation [RMI]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/541—Client-server
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/549—Remote execution
Abstract
The invention provides an event-driven method and system based on a state machine, which are applied to the field of transaction. The application applies the domain model to business processing in the transaction field, and fully decouples task flow, field objects and task execution through the instance module, the task module and the strategy module, so that the responsibility of each module is clearer, and the method also has good transverse and longitudinal expansion capability.
Description
Technical Field
The invention relates to a state machine-based event-driven method and system applied to the field of transactions.
Background
The transaction system is an information system which provides a human-computer interaction interface or has the functions of independent intelligent decision and issuing a transaction instruction, takes a transaction instruction transmission network as a channel and takes a computer as a carrier. Existing transaction systems mainly include the following types: trend following transaction system, counter trend transaction system, breakthrough transaction system, price interval transaction system and hedging system.
The existing transaction system mainly has two defects:
firstly, the design is based on the business process, the process is solidified in the system code, and the triggering is carried out through the timing task, which is not beneficial to the change of the business process and lacks the longitudinal expansibility.
And secondly, the lateral expansibility among all service varieties is not considered, namely, the service product elements and the service processing flow are not effectively separated, and the incorporation of new service varieties is not flexible enough.
Disclosure of Invention
In order to overcome the technical defect that the transaction system in the prior art lacks transverse expansibility and longitudinal expansibility, a first aspect of the invention provides a state machine-based event-driven method applied to the transaction field, wherein the event-driven method comprises the following steps:
step S1: after receiving a transaction confirmation instruction aiming at a transaction sent by a client or a first server, an instance module generates an instance of the transaction, updates the transaction state to be a first transaction state, sends the first transaction state to a task module, and distributes a transaction number to identify the transaction;
step S2: the task module acquires all events to be executed and all tasks contained in the events when the transaction is completed;
step S3: the task module determines a unique first current event which needs to be executed when the first transaction state enters the second transaction state and all first current tasks contained in the event, and distributes all the first current tasks to the instance module;
step S4: after receiving all the first current tasks, the instance module forwards all the first current tasks to the strategy module for processing;
step S5: the strategy module processes all the first current tasks and feeds back processing results to the instance module;
step S6: the instance module updates the transaction state into a second transaction state according to the processing result and sends the second transaction state to the task module; and
step S7: repeating the steps S3 to S6 in sequence until all tasks contained in all events needing to be executed when the transaction is completed are executed, and then the instance module performs persistence operation on the instance;
the instance module, the task module and the policy module are deployed at a second server. Illustratively, in step S7, the task module determines the only second current event that needs to be performed from the second trading state into the third trading state and all of its second current tasks involved, and then repeats steps S4 through S6 in sequence, and so on.
In the technical scheme of the application, the second server side realizes the event-driven method based on the state machine, which is applied to the transaction field, through the design of the abstract class and the field modeling. The client (or the first server) and the second server perform data communication, for example, the client (or the first server) sends a transaction confirmation instruction for a certain transaction to the second server, the second server receives the transaction confirmation instruction for the transaction, and so on.
"transaction" in this application includes, but is not limited to, the transaction activity of a business item such as a deposit, loan, ticket, bond, foreign exchange, etc.
Further, before step S1, the method further includes the steps of: and designing and coding based on a state machine and a field model to generate an event driving system, wherein the field model abstracts a transaction field object, the event driving system comprises the instance module, the task module and the strategy module, and the instance module, the task module and the strategy module surround the state of the transaction field object together and drive the event execution of the transaction field according to the state machine.
The term "transaction field object" in the present application refers to an object that is constructed for defining a transaction activity with respect to a visual representation of key things and their relationships in a transaction processing link.
In this application, "state machine" refers not to an actual machine, but to a mathematical model, and generally refers to a state transition diagram (i.e., a state machine diagram). A state machine will contain at least two states. Given a state machine, and given its current state and inputs, the output state can be unambiguously computed. The state of the process is switched according to a state diagram, and the business flow is performed around the state change of a certain thing. Typically, a finite state machine is used. The state machine can comb the service states, is clear at a glance, and can be increased continuously according to service scenes.
The term "domain model" in the present application refers to a visual representation of a concept class in the transaction domain or an object in the real world, and is also referred to as a concept model, a domain object model, or an analysis object model. Specifically, according to a design thought of a domain-driven design (DDD) commonly used in the field, a domain object and a domain event of a transaction field are packaged, an interface for operating the domain object is provided externally through a domain service layer to trigger management of a life cycle of the domain object, in the design, similarity of transaction objects of various business varieties on a transaction flow is fully considered, a congestion model is utilized, common elements and common methods are abstracted to form abstract classes, for example, deposit transaction classes are abstracted, JAVA is utilized, and specific objects of instances are used during operation, for example, live time, periodic time or deposit notification.
Events in the present application include, but are not limited to, element check, transaction type determination, settlement manner determination, transaction amount determination, transaction aging determination, wind control check, service confirmation, and the like.
Further, the instance module defines a specific domain object and a domain service, and provides an external interface to trigger the creation of the domain object; the task module realizes the configurability of the domain event and the domain flow, comprises three basic configurations of task control, event control and event configuration, and drives the domain event to execute through the state of the domain object; the strategy module defines the realization method of all field events, is a strategy warehouse for centralized management, and is a public method and an individual method for centralized management of each business variety; the instance module acquires a method for executing the domain event from the policy module, and then calls the task module to execute the method, so that the state of the domain object is changed, and finally persistence is finished.
Further, the task module comprises a policy library, a task configuration library and a task flow control library, wherein the policy library determines all subtasks of the current execution event of the domain object, the task configuration library determines the event or task to be executed by the domain object in a certain state, and the task flow control library provides flow control driven by the state. In step S4, the instance module forwards all the first current tasks to the policy module for processing according to the policy numbers and the domain object elements included in all the first current tasks.
The field object elements comprise a transaction instruction number, transaction time, transaction type, settlement mode, transaction amount, customer number, customer name, customer account number and the like.
Further, the instance module comprises an instance base, and the instance base contains instances corresponding to different transaction service types.
Preferably, the instance module, the task module and the policy module are respectively deployed at the same second server or different second servers.
A second aspect of the present invention provides a state machine-based event driven system applied to the field of transactions, the event driven system comprising an instance module, a task module and a policy module,
the instance module is used for generating an instance of the transaction after receiving a transaction confirmation instruction aiming at the transaction and sent by a client or a first server, and allocating a transaction number to identify the transaction; the system is also used for updating the transaction state to be a first transaction state and sending the first transaction state to the task module; the system is also used for receiving all the first current tasks distributed by the task module and then forwarding all the first current tasks to the strategy module for processing; the system is also used for updating the transaction state into a second transaction state according to the processing result of the strategy module and sending the second transaction state to the task module; and the method is also used for carrying out persistence operation on the instance after all tasks contained in all events needing to be executed when the transaction is completed are executed;
the task module is used for acquiring all events to be executed and all tasks contained in the events when the transaction is completed; the system is also used for determining the only first current event which needs to be executed for entering the second transaction state from the first transaction state and all the first current tasks contained in the event; and further for distributing all said first current tasks to instance modules;
the strategy module is used for processing all the first current tasks forwarded by the instance module and feeding back a processing result to the instance module;
the instance module, the task module and the policy module of the event-driven system are deployed at a second server.
Further, the event-driven system is designed and encoded based on a state machine and a domain model, the domain model is used for abstracting a transaction domain object, the event-driven system comprises the instance module, the task module and the policy module, and the instance module, the task module and the policy module are used for surrounding the state of the domain object together and driving the event execution of the transaction domain according to the state machine.
Events in the present application include, but are not limited to, element check, transaction type determination, settlement manner determination, transaction amount determination, transaction aging determination, wind control check, service confirmation, and the like.
Further, the instance module is used for defining specific domain objects and domain services, and providing external interfaces to trigger the creation of the transaction domain objects; the task module is used for realizing the configurability of the field event and the field flow, comprises three basic configurations of task control, event control and event configuration, and drives the field event to execute through the state; the strategy module is used for defining the implementation method of all field events, is a strategy warehouse for centralized management, and is a public method and an individual method for centralized management of various business varieties; the instance module is used for acquiring a method for executing the domain event from the policy module, and then calling the task module to execute the method, so that the state of the domain object is changed, and finally persistence is finished.
Further, the task module includes a policy library, a task configuration library and a task flow control library, the policy library is used for determining all subtasks of the current execution event of the domain object, the task configuration library is used for determining the event or task that needs to be executed by the domain object in a certain state, and the task flow control library is used for providing state-driven flow control. And the instance module is also used for forwarding all the first current tasks to the strategy module for processing according to the strategy numbers and the field object elements contained in all the first current tasks.
Further, the field object elements include a transaction instruction number, transaction time, transaction type, settlement method, transaction amount, customer number, customer name, customer account number and the like.
Further, the instance module comprises an instance base, and the instance base contains instances corresponding to different transaction service types.
Further, the instance module, the task module and the policy module are respectively deployed at the same second server or different second servers. Illustratively, the instance module, the task module and the policy module are all deployed at the same second server; or, exemplarily, the instance module is deployed at one second server, and the task module and the policy module are deployed together at another second server; or, exemplarily, the instance module, the task module and the policy module are respectively deployed at three different second servers, and so on.
After the technical scheme is adopted, compared with the prior art, the method has the following beneficial effects:
1. the transaction field has complexity, for example, transaction processing links and transaction states are very many, and in the prior art, a transaction system is designed based on a business process, the business process is solidified in a system code and is triggered by a timing task, so that the change of the business process is not facilitated, and longitudinal expansibility is lacked. The application applies a domain model to the transaction field, and the event-driven system based on the state machine applied to the transaction field is executed based on transaction state-driven events, namely, state change and event execution are combined together, namely, a certain event is executed in the current state, and the next state is carried out according to an execution result, and the execution is sequentially and repeatedly carried out. For a certain business variety, the business process can be changed at will, and the business process is not solidified in the system code any more, so the event-driven system based on the state machine applied to the transaction field has longitudinal expansibility.
2. In the prior art, the service product elements of the transaction system are coupled with the service processing flow, the new service varieties are not flexible to be brought into, and the transverse expansibility among all the service varieties is not considered. The event driving system based on the state machine applied to the transaction field fully decouples task flow, field objects and task execution through the instance module, the task module and the strategy module, so that the responsibility of each module is clearer, and meanwhile, the event driving system has good transverse and longitudinal expansion capabilities. Specifically, the instance module focuses on modeling of the domain object, a finite state machine of the domain object, defining domain services, and exposing a domain service interface to the outside, so that the method not only can support the transaction of each existing business variety (such as deposit, loan, bill, bond, foreign exchange, etc.), but also can separate the domain state change from the specific business transaction elements in an abstract mode, and also can meet the requirement of bringing in more business varieties in the future, and has lateral expansibility. Meanwhile, with the increase of the traffic, as the instance module has no status, the service can be transversely split, and transverse expansion is performed by adding the server. The task module can flexibly support different business varieties and different requirements of business products on transaction processing in a configuration mode, and meanwhile, longitudinal expansion capability is provided for increasing and decreasing different strategies. Multi-version management may also be introduced in the future to support business requirements in different overseas regions.
Drawings
FIG. 1 is a schematic diagram of a transaction state machine according to an embodiment of the present application;
FIG. 2 is a diagram of a transaction state machine incorporating an embodiment of the present application;
FIG. 3 is a schematic diagram of a communication relationship between a client and a first server and a second server deployed with an event-driven system;
fig. 4 is a flowchart of the state machine-based event-driven method applied to the field of transaction according to the present application.
Detailed Description
The advantages of the invention are further illustrated in the following description of specific embodiments in conjunction with the accompanying drawings. It is to be understood by persons skilled in the art that the following detailed description is illustrative and not restrictive, and is not to be taken as limiting the scope of the invention.
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.
The terminology used in the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, a first server may also be referred to as a second server, and similarly, a second server may also be referred to as a first server without departing from the scope of the present disclosure. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Examples
Event-driven system applied to transaction field and taking state machine diagram as design basis to design and generate application
(1) And (3) state drive design: a State Machine, i.e., a State Machine, refers not to an actual Machine, but to a mathematical model, which is generally a State transition diagram. A state machine will contain at least two states. Given a state machine, and given its current state and inputs, the output state can be unambiguously computed. The state of the process is switched according to a state diagram, and the business flow is performed around the state change of a certain thing. Typically, a finite state machine is used. The state machine can comb the service states, is clear at a glance, and can be increased continuously according to service scenes.
Fig. 1 is a schematic diagram of a transaction state machine according to an embodiment of the present application, in which different transaction states are used as nodes. As can be seen from the figure, the event execution is combined with the state change, that is, by executing a certain event in the current state, proceeding to the next state according to the execution result, and repeating the process in sequence. An event is a trigger or password for performing an operation, and a task is to be performed after the event occurs. The design uses a state machine diagram as a main design basis to identify a series of changes of an entity from an initial state to a final state. The two states are connected through a directional arrow, the fact that the former state can reach the latter state is marked, and characters on the directional arrow represent events triggering the state change and results of the event execution. All states and events on the state transition diagram not only indicate that the migration process of the state is a limited state change process, but also indicate the state which needs to be satisfied by the execution of the event.
By way of example, FIG. 2 illustrates a transaction state machine diagram of one embodiment of the present application.
Illustratively, when configuring these key information on the state machine diagram during the encoding process, the data structures as table 1 to table 3 are adopted:
TABLE 1 Process control architecture for transaction tasks employed when configuring a task Process control library
TABLE 2 control structure of tasks and events employed in configuring a task configuration library
Table 3 event configuration design structure used when configuring policy base
For the domain event, a specific execution method and parameters used by the method (namely, according to domain object elements defined by the completion of the domain) can be defined, and a plurality of subtasks can be supported and configured according to a certain execution sequence.
(2) Designing a domain object: according to the thought of Domain Driven Design (DDD), the domain object and the domain event are packaged, and the management of the life cycle of the domain object is triggered by providing an interface for the operation of the domain object to the outside through a domain service layer. In the design, the similarity of transaction objects of various business varieties on a transaction flow is fully considered, and the 'congestion model' is utilized to abstract elements and methods of the commonalities to form abstract classes, such as abstract deposit transaction classes, and then JAVA polymorphism is utilized to implement concrete objects of runtime instances, such as current or regular or notice deposit and the like.
Illustratively, in configuring the elements contained in the abstract class of the trading domain object, the data structure shown in table 4 is used to implement:
table 4 certain data structure of elements contained in abstract classes
The data state field is used for a state field of the state machine change, and the content of the field needs to be consistent with the state of the state transition diagram.
Through the process, the event-driven system based on the state machine, which is applied to the transaction field, can be obtained, and the event-driven system can be divided into three modules functionally. When the program code of the event-driven system is executed, the event-driven method based on the state machine, which is applied to the transaction field, is realized, so that the event execution inside each transaction business variety and the event execution among different transaction business varieties are realized. The event driving system based on the state machine, which is applied to the field of transaction, fully decouples task flow, field objects and task execution, so that the responsibility of each module is clearer, and the event driving system has good transverse and longitudinal expansion capabilities.
Wherein the instance module: according to the design concept of DDD, a specific field object and field service are defined, an interface is provided externally, the creation of the field object is triggered, a field event execution method is obtained from a strategy module, and then a task module is called to execute the method, so that the state of the field object is changed, and a series of operations such as persistence and the like are finally completed. The instance module is focused on modeling of the domain object, a finite state machine of the domain object, defining domain service and externally exposing a domain service interface, can support the transaction (such as deposit, loan, bill, bond, foreign exchange and the like) of each existing business variety, also separates the domain state change from the specific business transaction element in an abstract mode, also solves the requirement of bringing in more business varieties in the future and has certain horizontal expansibility. Meanwhile, with the increase of the traffic, as the instance module has no status, the service can be transversely split, and transverse expansion is performed by adding the server.
Wherein, the task module: the field event and the field flow can be configured, and the field event is driven to be executed through the state. The method comprises three basic configurations of task control, event control and event configuration, so that developers can flexibly configure according to different requirements of services. Through the configuration mode, the differentiation requirements of different service varieties and service products on transaction processing can be flexibly supported, and meanwhile, the longitudinal expansion capability is provided for increasing and decreasing different strategies. Multi-version management may also be introduced in the future to support business requirements in different overseas regions.
Wherein the policy module: the method defines the realization method of events in all fields, is a centralized management strategy warehouse, and ensures that the public method and the individual method of each business variety are managed in a centralized way. The operation results obtained by executing these methods can be used to judge the change of the state of the field.
Second, practical application of event-driven system in transaction field of the present application
As shown in fig. 3, the event-driven system based on the state machine, applied to the field of transaction, of the present application is deployed at the second server, and includes an instance module, a task module, and a policy module. The client (or the first server) and the second server are in data communication. When the program code of the event-driven system is executed, the event-driven method based on the state machine, which is applied to the transaction field, is realized, so that the event execution inside each transaction business variety and the event execution among different transaction business varieties are realized.
As shown in fig. 2 and 4, the state machine-based event-driven method applied to the transaction field includes the steps of:
step S1: after receiving a transaction confirmation instruction for a transaction sent by a client or a first server, an instance module generates an instance of the transaction, updates a transaction state to a first transaction state (namely an initial state), and sends the first transaction state to a task module.
Step S2: and the task module acquires all events needing to be executed when the transaction is completed and all tasks contained in the events.
Specifically, the task module obtains all events that need to be executed when the transaction is completed and all tasks included in the events, for example, all events are: deduplication (i.e., predicting whether the transaction instruction is repeated), pre-check pass, purchase transaction, cash-out transaction, recharge transaction, real-time aging, and aging every other day.
Step S3: the task module determines the only first current event which needs to be executed from the first transaction state to the second transaction state and all the first current tasks contained in the event, and distributes all the first current tasks to the instance module.
Specifically, the task module determines that a current event required to be executed from the first transaction state to the second transaction state is 'deduplication', and allocates all first current tasks corresponding to 'deduplication' to the instance module.
Step S4: and after receiving all the first current tasks, the instance module forwards all the first current tasks to the strategy module for processing.
Specifically, after receiving all the first current tasks corresponding to the 'duplicate removal', the instance module forwards all the first current tasks to the policy module for processing.
Step S5: and the strategy module processes all the first current tasks corresponding to the 'duplicate removal' and feeds back the processing result to the instance module.
Step S6: and the instance module updates the transaction state into a second transaction state according to the processing result and sends the second transaction state to the task module. And
step S7: and repeating the steps S3 to S6 in sequence until all tasks included in all events needing to be executed when the transaction is completed are executed, updating the transaction state to a final transaction state (namely a final state), and performing a persistence operation on the instance by the instance module.
For the transaction states starting from the second transaction state to the final transaction state (i.e., the final state), the updating of each two adjacent transaction states needs to perform one pass from step S3 to step S6.
Illustratively, first, the task module performs step S3 to determine that the current event to be executed from the second transaction state to the third transaction state is "pre-check pass", and all the second current tasks corresponding to "pre-check pass" are allocated to the instance module. Then, by analogy, steps S4 to S6 are repeatedly performed in order.
Secondly, (1) the task module determines that the current event to be executed from the third transaction state to the fourth transaction state is "purchase transaction", and allocates all current tasks corresponding to the "purchase transaction" to the instance module, and then repeats steps S4 to S6 in sequence, because the fourth transaction state is the final state, all tasks included in all events to be executed after the transaction is completed are executed, and the instance module performs persistence operation on the instance;
or, (2) the task module determines that the current event to be executed from the third transaction state to the fifth transaction state is a "top-up transaction", allocates all current tasks corresponding to the "top-up transaction" to the instance module, and repeats steps S4 to S6 in sequence by analogy; then, further, the task module determines that the current event needing to be executed from the fifth transaction state to the seventh transaction state is "real time", and allocates all current tasks corresponding to the "real time" to the instance module, and then repeats the steps S4 to S6 in sequence by analogy, because the seventh transaction state is the final state, all tasks included in all events needing to be executed by the transaction have been executed, and the instance module performs the persistence operation on the instance; or, the task module determines that the current event to be executed from the fifth transaction state to the eighth transaction state is "every other day", and allocates all current tasks corresponding to the "every other day" to the instance module, and then repeats steps S4 to S6 in sequence by analogy, because the eighth transaction state is the final state, all tasks included in all events to be executed after the transaction is completed are executed, and the instance module performs persistence operation on the instance;
or, (3) the task module determines that the current event required to be executed from the third transaction state to the sixth transaction state is a "cash-out transaction", and allocates all current tasks corresponding to the "cash-out transaction" to the instance module, and then repeats the steps S4 to S6 in sequence, because the sixth transaction state is a final state, all tasks included in all events required to be executed by the transaction have been executed, and the instance module performs a persistence operation on the instance.
It should be understood by those skilled in the art that fig. 1 and fig. 2 in the detailed description of the present application are only examples of a certain embodiment for facilitating understanding of the technical solution of the present invention, and due to diversity and redundancy of transaction varieties and flows thereof in the transaction field, due to space limitation, all transaction varieties cannot be exhausted and all complete transaction flows under a certain variety cannot be exhausted, but understanding and implementation of the technical solution of the present application by those skilled in the art are not affected.
In summary, the event-driven system based on the state machine applied to the transaction field fully decouples task flow, field objects and task execution through the instance module, the task module and the policy module, so that the responsibility of each module is clearer, and meanwhile, the event-driven system has good transverse and longitudinal expansion capabilities.
It should be noted that the embodiments of the present invention have been described in terms of preferred embodiments, and not by way of limitation, and that those skilled in the art can make modifications and variations of the embodiments described above without departing from the spirit of the invention.
Claims (10)
1. A state machine-based event-driven method applied to the field of transaction is characterized by comprising the following steps:
step S1: after receiving a transaction confirmation instruction aiming at a transaction sent by a client or a first server, an instance module generates an instance of the transaction, updates the transaction state to a first transaction state and sends the first transaction state to a task module;
step S2: the task module acquires all events to be executed and all tasks contained in the events when the transaction is completed;
step S3: the task module determines a unique first current event which needs to be executed when the first transaction state enters the second transaction state and all first current tasks contained in the event, and distributes all the first current tasks to the instance module;
step S4: after receiving all the first current tasks, the instance module forwards all the first current tasks to the strategy module for processing;
step S5: the strategy module processes all the first current tasks and feeds back processing results to the instance module;
step S6: the instance module updates the transaction state into a second transaction state according to the processing result and sends the second transaction state to the task module; and
step S7: repeating the steps S3 to S6 in sequence until all tasks contained in all events needing to be executed when the transaction is completed are executed, and then the instance module performs persistence operation on the instance;
the instance module, the task module and the policy module are deployed at a second server.
2. The state-machine based event-driven method applied to the transaction field of claim 1, further comprising, before the step S1, the steps of: and designing and coding based on a state machine and a field model to generate an event driving system, wherein the field model abstracts a transaction field object, the event driving system comprises the instance module, the task module and the strategy module, and the instance module, the task module and the strategy module surround the state of the transaction field object together and drive the event execution of the transaction field according to the state machine.
3. The state-machine based event driven method applied to the transaction field of claim 2, wherein the instance module defines specific transaction field objects and field services, provides external interfaces to trigger creation of field objects; the task module realizes the configurability of the domain event and the domain flow and drives the domain event to execute through the state of the domain object; the strategy module defines the realization method of all field events, and a public method and an individual method for managing all service varieties in a centralized way; the instance module acquires a method for executing the domain event from the policy module, and then calls the task module to execute the method, so that the state of the domain object is changed, and finally persistence is finished.
4. The state-machine based event-driven method applied to the transaction field according to claim 2, wherein the task module comprises a policy library, a task configuration library and a task flow control library, the policy library determines all subtasks of the current execution event of the transaction field object, the task configuration library determines the event or task that the transaction field object needs to execute in a certain state, and the task flow control library provides flow control driven by the state.
5. The state-machine based event-driven method applied to the transaction field as claimed in claim 1, wherein the instance module comprises an instance library, and the instance library contains instances corresponding to different transaction service types.
6. A state machine-based event driven system applied to the transaction field is characterized in that the event driven system comprises an instance module, a task module and a strategy module,
the instance module is used for generating an instance of the transaction after receiving a transaction confirmation instruction aiming at the transaction and sent by the client or the first server; the system is also used for updating the transaction state to be a first transaction state and sending the first transaction state to the task module; the system is also used for receiving all the first current tasks distributed by the task module and then forwarding all the first current tasks to the strategy module for processing; the system is also used for updating the transaction state into a second transaction state according to the processing result of the strategy module and sending the second transaction state to the task module; and the method is also used for carrying out persistence operation on the instance after all tasks contained in all events needing to be executed when the transaction is completed are executed;
the task module is used for acquiring all events to be executed and all tasks contained in the events when the transaction is completed; the system is also used for determining the only first current event which needs to be executed for entering the second transaction state from the first transaction state and all the first current tasks contained in the event; and further for distributing all said first current tasks to instance modules;
the strategy module is used for processing all the first current tasks forwarded by the instance module and feeding back a processing result to the instance module;
the instance module, the task module and the policy module of the event-driven system are deployed at a second server.
7. The state-machine based event driven system applied to the transaction field of claim 6, wherein the event driven system is designed and encoded based on a state machine and a field model, the field model is used for abstracting a transaction field object, the event driven system comprises the instance module, the task module and the policy module, and the instance module, the task module and the policy module are used for surrounding the state of the transaction field object together and driving the event execution of the transaction field according to the state machine.
8. The state-machine based event driven system for the transaction domain as claimed in claim 7, wherein the instance module is used to define specific transaction domain objects and domain services, provide external interfaces to trigger the creation of domain objects; the task module is used for realizing the configurability of the domain event and the domain flow and driving the domain event to execute through the state; the strategy module is used for defining the realization methods of all field events, and managing the public method and the individual method of each business variety in a centralized way; the instance module is used for acquiring a method for executing the domain event from the strategy module, and then calling the task module to execute the method, so that the state of the transaction domain object is changed, and finally persistence is finished.
9. The state-machine based event-driven system applied to the transaction field of claim 7, wherein the task module comprises a policy library, a task configuration library and a task flow control library, the policy library is used for determining all subtasks of the current execution event of the field object, the task configuration library is used for determining the event or task which needs to be executed by the transaction field object in a certain state, and the task flow control library is used for providing flow control driven by the state.
10. The state-machine based event driven system applied to the transaction field as claimed in claim 6, wherein the instance module comprises an instance library containing instances corresponding to different transaction service types.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110697789.0A CN113626209B (en) | 2021-06-23 | 2021-06-23 | Event driving method and system based on state machine applied to transaction field |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110697789.0A CN113626209B (en) | 2021-06-23 | 2021-06-23 | Event driving method and system based on state machine applied to transaction field |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113626209A true CN113626209A (en) | 2021-11-09 |
| CN113626209B CN113626209B (en) | 2024-01-26 |
Family
ID=78378217
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110697789.0A Active CN113626209B (en) | 2021-06-23 | 2021-06-23 | Event driving method and system based on state machine applied to transaction field |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113626209B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116775170A (en) * | 2023-08-03 | 2023-09-19 | 中体彩彩票运营管理有限公司 | Event driven software system and method based on finite state machine and rule engine |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101201753A (en) * | 2007-12-13 | 2008-06-18 | 浪潮通信信息系统有限公司 | Method for configuring and managing multimode machine supervising engine |
| CN106227584A (en) * | 2016-07-28 | 2016-12-14 | 武汉聚风天下科技有限公司 | A kind of event-driven method based on state machine and system |
| US20180329761A1 (en) * | 2017-05-10 | 2018-11-15 | International Business Machines Corporation | Integrating transaction processing system interfaces with event-driven polyglot runtime modules |
| CN111144982A (en) * | 2019-12-20 | 2020-05-12 | 网联清算有限公司 | Order state transition method and device, electronic equipment and storage medium |
-
2021
- 2021-06-23 CN CN202110697789.0A patent/CN113626209B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101201753A (en) * | 2007-12-13 | 2008-06-18 | 浪潮通信信息系统有限公司 | Method for configuring and managing multimode machine supervising engine |
| CN106227584A (en) * | 2016-07-28 | 2016-12-14 | 武汉聚风天下科技有限公司 | A kind of event-driven method based on state machine and system |
| US20180329761A1 (en) * | 2017-05-10 | 2018-11-15 | International Business Machines Corporation | Integrating transaction processing system interfaces with event-driven polyglot runtime modules |
| CN111144982A (en) * | 2019-12-20 | 2020-05-12 | 网联清算有限公司 | Order state transition method and device, electronic equipment and storage medium |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116775170A (en) * | 2023-08-03 | 2023-09-19 | 中体彩彩票运营管理有限公司 | Event driven software system and method based on finite state machine and rule engine |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113626209B (en) | 2024-01-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102999816B (en) | The workflow engine of personalized operation flow | |
| CN106371918A (en) | Task cluster scheduling management method and apparatus | |
| US20100036704A1 (en) | Method and system for allocating requirements in a service oriented architecture using software and hardware string representation | |
| CN110399119A (en) | A kind of modularization construction method, device, electronic equipment and storage medium | |
| CN109101334A (en) | A kind of micro services concurrency control method towards Zuul gateway | |
| CN109508344A (en) | Business datum querying method, device, electronic equipment and storage medium | |
| EP1715451A1 (en) | A data processing system having a service oriented architecture | |
| CN112506498A (en) | Intelligent visual API arrangement method, storage medium and electronic equipment | |
| CN112463211A (en) | System architecture transformation method compatible with multiple development architectures and system architecture | |
| WO2003005167A2 (en) | Business process policy object | |
| AU2002354789A1 (en) | Business process policy object | |
| CN109150957A (en) | A kind of micro services concurrent control system | |
| CN101286212A (en) | Business flow path execution method, business flow path engines and its deployment method | |
| CN108846564A (en) | Server, the method for waiting and storage medium | |
| CN103164774A (en) | Automobile complete vehicle development system based on workflow | |
| CN113626209A (en) | State machine-based event-driven method and system applied to transaction field | |
| CN115185496A (en) | Service arrangement method based on Flowable workflow engine | |
| CN106897060A (en) | Based on patterned data processing method and device | |
| CN109785047A (en) | Order method for pushing, device, computer equipment and the storage medium of financial product | |
| CN107025134A (en) | The method of database management systems and compatible multitype database | |
| Wohed et al. | Pattern Based Analysis of Eai Languages-The Case of the Business Modeling Language. | |
| CN109634714A (en) | A kind of method and device of intelligent scheduling | |
| CN109118065A (en) | A kind of interactive mode Workflow system and its operation method | |
| Souza et al. | Service identification in aspect-oriented business process models | |
| CN102214094B (en) | Operation is performed via asynchronous programming model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |