General order state machine and system based on multiple categories of SAAS platform

Abstract

The invention discloses a general order state machine and system based on multiple categories of an SAAS platform. The invention relates to the technical field of SAAS platforms. Loading a state machine engine configuration file, and initializing a state machine engine environment; scanning and registering a processor, and constructing a processor mapping table according to dimensions of multiple states, multiple channels and multiple events; after a new order state circulation request is received, related information is acquired from the context according to the order ID and the current state in the request. Reading and analyzing a configuration file of the state machine engine, wherein the configuration file comprises an initialization parameter, a state definition, an event definition and a state conversion rule of the state machine engine; according to parameters in the configuration file; according to the invention, through clearly defined states and conversion rules, the whole flow of designated driving service becomes more standard and controllable, and the possibility of human intervention and misoperation is reduced. The automatic execution of the state machine engine enables the order state to quickly and accurately respond to various events and conditions.

Description

Technical Field

[0001] The present invention relates to the technical field of SAAS platform, specifically to the technical field of platform of designated driver service type, and especially to a general order state machine and system based on multiple categories of SAAS platform. Background Art

[0002] With the rapid development of cloud computing technology, the service model based on the Software-as-a-Service (SaaS) platform has become an important part of the modern service industry. Among them, the accuracy and efficiency of the order processing process of the designated driver service, as an emerging service industry that is highly dependent on information management, is crucial to improving user experience and service quality. This paper will deeply explore the design and optimization of the order processing process in the designated driver service from a technical perspective, especially by building a finite state machine (FSM) model to effectively manage the life cycle of the order.

[0003] In complex travel service scenarios, order status management faces multiple challenges. The primary challenge is how to accurately define the various states of an order and the specific triggering conditions for each state transition. For example, to transition from the "pending payment" state to the "paid" state, it is necessary to ensure that the user has completed the payment operation and that the payment platform returns a successful confirmation message. In a high-concurrency environment, it is crucial to maintain the atomicity of order state transitions to avoid state inconsistencies. This requires system design that can prevent the same order from being mistakenly marked as multiple states at the same time, such as being displayed as "starting the trip" and "cancelled" at the same time.

[0004] At the same time, in the face of emergencies such as payment failures and route planning anomalies, the system needs to have a complete exception handling mechanism that can quickly and accurately transfer the order status to the appropriate abnormal status, such as "payment failure" or "order cancellation", while ensuring that the rights and interests of users and service providers are properly handled.

[0005] The processing flow of the designated driver order can be regarded as an application example of a finite state machine. In this model, the entire life cycle of an order from creation to completion is subdivided into a series of clear states, such as "order placement", "driver acceptance of order", "start of trip", "end of trip", "pending payment", "paid", "shipping", "completed" and "cancelled order". Each state represents the clear status of an order at a specific point in time, and the transition between states depends on specific events or conditional triggers, ensuring the sequentiality and logic of the order processing logic. To this end, the present invention proposes a general order state machine and system based on multiple categories of SAAS platforms. Summary of the invention

[0006] In view of this, the present invention hopes to provide a general order state machine and system based on multiple categories of SAAS platforms to solve or alleviate the technical problems existing in the prior art, that is, how to abstract the traditional SAAS platform's designated driver service into an order state machine, solve the problem of clarity of state definition and conversion rules and the atomicity and consistency of state conversion, and at least provide a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0007] First, a general order state machine based on multiple categories of SAAS platforms:

[0008] 1. Overview:

[0009] The present invention aims to build an efficient, flexible and scalable order status management mechanism to realize the automatic flow of order status in multi-channel and multi-event scenarios. It uses a state machine engine as the core driver, initializes the state machine environment by loading configuration files, and registers multiple processors to cope with different states, events and channel combinations. These processors perform corresponding data preparation, business logic, data persistence and subsequent processing operations according to the current order status, triggered events and channel information, thereby ensuring that the order status can be updated accurately and in a timely manner. In addition, the solution also supports the construction of processors in multiple dimensions, making the state flow logic clearer and easier to manage. Through the asynchronous event notification mechanism, related systems or components can obtain changes in order status in a timely manner and make corresponding responses.

[0010] (II) Technical solution:

[0011] To achieve the above technical objectives, upon receiving the input order state machine scheme activation instruction, initializing the state machine engine and registering the processor, the present invention selects to execute the following operation steps.

[0012] 2.1 Step S1, system initialization:

[0013] Load the state machine engine configuration file and initialize the state machine engine environment; scan and register the processor, and build a processor mapping table based on the dimensions of multi-state, multi-channel, and multi-event;

[0014] When a new order status transfer request is received, relevant information is obtained from the context based on the order ID and current status in the request.

[0015] 2.1.1 Step S100, load the state machine engine configuration file:

[0016] Read and parse the configuration file of the state machine engine, including the initialization parameters, state definition, event definition, and state transition rules of the state machine engine.

[0017] Initialize the running environment of the state machine engine according to the parameters in the configuration file, including the creation of state machine instances, the initialization of state lists, and the setting of event listeners.

[0018] 2.1.2 Step S101, scan and register the processor:

[0019] Scan the processor classes in the system based on the dimensions of multi-state, multi-channel and multi-event;

[0020] The scanned processor class is registered in the state machine engine, and a processor mapping table is constructed based on the state, event, and channel information it supports; this mapping table is used to quickly find and call the corresponding processor in the subsequent state flow process.

[0021] 2.1.3 Step S102, constructing context:

[0022] Create a context object for each order to store all relevant information during the order status flow, including order ID, current status, events, and channel information;

[0023] Store the context object in memory or in a database so that it can be quickly retrieved when a new order status flow request is received.

[0024] 2.2 Step S2, obtain processor:

[0025] According to the order status, event and channel information in the context, obtain the corresponding processor from the processor mapping table; call the data preparation method of the processor to prepare the data required for the execution state flow.

[0026] 2.2.1 Step S200, obtaining order information:

[0027] When receiving a new order status transfer request, parse the order ID and current status in the request;

[0028] Based on the order ID, obtain all information related to the order from the context, including order status, events, and channel information;

[0029] 2.2.2 Step S201, search for processor:

[0030] According to the order status, event and channel information in the context, the corresponding processor is found in the processor mapping table; the data preparation method of the found processor is called to prepare all the data required for the execution state flow.

[0031] 2.3 Step S3, the processor executes:

[0032] Call the processor's get next state method to determine the next state based on the current state and events; call the processor's business logic execution (action) method to execute the core business logic of state transfer; the specific solution is:

[0033] In the processor, the method to obtain the next state is called according to the current state and events; the business logic execution (action) method of the processor is called, which contains the core business logic of the state flow, including updating order information and calculating fees.

[0034] 2.4 Step S4, the processor executes:

[0035] The data persistence (save) method of the processor is called to persist the results of the state flow to the database; at this stage, the relevant plug-ins will be loaded and executed to process the logic before data persistence.

[0036] Call the processor's after method to execute the subsequent processing logic after the state transfer, including sending notifications and updating caches;

[0037] After the processor is executed, the background sends an event notification asynchronously to notify the component of the change in order status.

[0038] 2.4.1 Step S400, data persistence:

[0039] Before or after data persistence (depending on business logic requirements), load and execute relevant data validation and data conversion plug-ins.

[0040] 2.4.2 Step S401, execute subsequent processing logic

[0041] After data persistence is completed, the processor's subsequent processing (after) method is called. The subsequent processing method is the subsequent processing logic after the state flow, including sending notifications (SMS, emails) and updating cache.

[0042] 2.4.3 Step S402, asynchronously sending event notification:

[0043] After the processor is executed, it prepares relevant information for the event notification, including the order ID, status change, and timestamp; sends the event notification information to the background message queue or event bus, which is asynchronously processed by a dedicated notification component and sends notifications to related systems or users.

[0044] 2.5 Step S5, order status flow ends / enters loop:

[0045] If the order status transfer is completed, update the order status to the final status and end this process;

[0046] If the order status flow needs to enter the next cycle (such as waiting for user operation, waiting for external system response, etc.), the order status is set to the waiting state and waits for the next event to be triggered.

[0047] 2.5.1 Step S500, update the order status to the final status (if the flow is completed):

[0048] If the order status transfer is completed, modify the order status field in the database and update the order status in the cache; after the status update is completed, end the order status transfer process and release resources.

[0049] 2.5.2 Step S501, set the order status to waiting status (if it is necessary to enter the next cycle):

[0050] Set the order status to a confirmed waiting status and save the waiting information of the waiting event type and timeout period.

[0051] 2.5.3 Step S502, waiting for the next event to be triggered (if in waiting state)

[0052] Set up an event listener to monitor the next event related to the order, including user operation events and external system response events;

[0053] While waiting for an event to be triggered, keep the order status in the waiting state and prepare the data and logic required to process the next event;

[0054] When the next event is triggered, the corresponding processing logic is executed according to the event type and business logic, and step S2 is restarted.

[0055] (III) Mechanism for solving technical problems:

[0056] 3.1 Clarity of state definition and conversion rules:

[0057] The chauffeur service process is abstracted into a series of clear and specific states, such as waiting for orders, received orders, driving, completed, etc. Each state represents a specific stage in the chauffeur service process.

[0058] Define clear transition rules for each state, that is, the events and conditions that trigger state transitions. For example, when a driver accepts an order, the order state transitions from "pending order" to "accepted order". Use configuration files to define the initialization parameters and settings of the state machine engine, including state lists, event lists, transition rules, etc.

[0059] By registering a processor, each state and its transition rules are associated with the corresponding processing logic, enabling flexible configuration and expansion of the state machine engine.

[0060] 3.2 Atomicity and consistency of state transition:

[0061] During the state transition process, a synchronization mechanism (such as database transactions, lock mechanisms, etc.) is used to ensure the atomicity of the state transition. That is, once the state transition begins, it must be ensured that the transition process is completely completed without partial transition.

[0062] When executing business logic, the processor ensures that each state transition operation is an indivisible atomic operation to avoid interruption or interference during the transition process.

[0063] Second, a general order state machine system based on multiple categories of SAAS platforms:

[0064] like Figure 3 As shown, the system is used to implement the above-mentioned general order state machine and system based on multiple categories of SAAS platform, which includes:

[0065] (1) Responsible for loading the state machine engine configuration file and initializing the system initialization module of the state machine engine environment: scanning and registering processors, and building a processor mapping table based on the dimensions of multi-state, multi-channel, and multi-event.

[0066] (2) An order status flow processing module for order status conversion, which includes:

[0067] (2.1) According to the order status, event and channel information in the context, obtain the corresponding processor from the processor mapping table and call its data preparation method.

[0068] (2.2) Responsible for calling the processor's get next state method and determining the processor execution submodule of the next state: executing the core business logic of state flow. Calling the data persistence method, saving the state flow results to the database, and loading and executing related plug-ins. Executing subsequent processing logic, such as sending notifications and updating caches.

[0069] (3) After the processor completes execution, it asynchronously sends an event notification to notify the relevant components of the change in order status. The event notification and status update module: based on the result of the order status flow, it updates the order status or sets the order to a waiting state to enter the next cycle.

[0070] Compared with the prior art, the present invention has the following beneficial effects:

[0071] 1. Improved efficiency and accuracy of designated driver services: The present invention makes the entire process of designated driver services more standardized and controllable through clearly defined states and conversion rules, reducing the possibility of human intervention and misoperation. The automated execution of the state machine engine enables the order status to respond quickly and accurately to various events and conditions, improving the response speed and accuracy of the service.

[0072] Second, the stability and reliability of the system are enhanced: The atomicity and consistency of the state transition of the present invention ensure the consistency and integrity of the order status in multiple nodes and systems, avoiding data conflicts and loss problems. The exception handling mechanism can timely discover and handle potential faults and errors, ensuring the stable operation of the system and improving the reliability and availability of the designated driver service.

[0073] 3. Improved system scalability and maintainability: Through the design of configuration files and registration processors, the present invention can flexibly add new states and conversion rules to meet changing business needs. The modular design of the processor makes the code clearer, easier to understand and maintain, and reduces the complexity and maintenance cost of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0075] Figure 1 It is a schematic diagram of the method of the present invention;

[0076] Figure 2 It is a schematic diagram of the execution flow of the method of the present invention;

[0077] Figure 3 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0078] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0079] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0080] Explanation of relevant terms:

[0081] (1) State Machine Engine: A core mechanism that drives the flow of order status and automatically executes state transitions based on predefined state and event rules.

[0082] (2) Configuration file: A file that contains the parameters and settings required to initialize the state machine engine and is used to configure the behavior of the state machine engine.

[0083] (3) Registering a processor: The process of associating a processor with a specific state, event, and channel so that the corresponding processor can be found and executed when the state flows.

[0084] (4) Multiple states: An order may exist in multiple different states, such as pending payment, paid, shipped, etc.

[0085] (5) Multi-channel: Orders may come from multiple different channels, such as online shopping malls, offline stores, third-party platforms, etc.

[0086] (6) Multiple events: multiple different events that can trigger changes in order status, such as user payment, system cancellation, logistics update, etc.

[0087] (7) Dimensional construction of processors: This method builds and organizes processors based on the three dimensions of state, event, and channel to more efficiently manage and execute state flow logic.

[0088] (8) Current status: The specific status of an order at a certain moment.

[0089] (9) Context: An environment or container that contains all the information and data required during the order status flow, such as order ID, current status, events, etc.

[0090] (10) Order Status: An identifier indicating the current stage or status of an order.

[0091] (11) Event: The reason or condition that triggers the change of order status.

[0092] (12) Channel information: the specific channel information where the order originates or the transaction occurs.

[0093] (13) Processor data preparation method: The method used by the processor to prepare the required data before executing the state flow.

[0094] (14) Business logic execution (action) method: The method that executes specific business logic in the processor is the core part of the state flow.

[0095] (15) Core business logic: The most important business logic directly related to the order status flow.

[0096] (16) Data persistence (save) method: a method that saves the results of state flow to a database or other persistent storage.

[0097] (17) After method: A method that executes additional processing logic after the state transfer is completed, such as sending notifications, updating cache, etc.

[0098] Embodiment 1: Figures 1-2 As shown, this embodiment discloses a general order state machine based on multiple categories of SAAS platform; in the order status fulfillment process, the operation steps are abstracted, and there will be three processes in each order status flow process: verification, business logic execution, and data update persistence; so again abstracted, a state flow can be divided into six stages: data preparation (prepare) → verification (check) → getting the next state (getNextState) → business logic execution (action) → data persistence (save) → subsequent processing (after); then a template method is used to connect the six stage methods together to form a sequential execution logic. In this way, the execution logic of the entire state process is clearer and simpler, and the maintainability is also improved to a certain extent.

[0099] In the SAAS online car-hailing platform, order status management is a key part of implementing business logic. The platform needs to handle multiple order states (such as pending, in progress, completed, etc.) and perform state transitions based on different events (such as user calling a car, driver accepting an order, end of trip, etc.). By introducing the order state machine solution, the state definition and transition rules can be clarified to ensure the atomicity and consistency of state transitions.

[0100] In this embodiment, regarding step S1: system initialization:

[0101] Specifically, load the state machine engine configuration file (S100): read and parse the configuration file of the state machine engine, which defines the initialization parameters, states (such as pending orders, in progress, completed), events (such as user calling a car, driver accepting an order) and state transition rules of the state machine engine.

[0102] Initialize the running environment of the state machine engine according to the parameters in the configuration file, including creating a state machine instance, initializing the state list, and setting event listeners.

[0103] Specifically, scanning and registering processors (S101): scanning processor classes in the system according to the dimensions of multiple states, multiple channels (such as APP, web page) and multiple events.

[0104] Register the scanned processor class to the state machine engine, and build a processor mapping table based on the state, event, and channel information it supports. This mapping table is used to quickly find and call the corresponding processor.

[0105] Specifically, construct a context (S102): create a context object for each order to store all relevant information during the order status flow, including order ID, current status (such as pending orders), events (such as user calling a car) and channel information (such as APP).

[0106] Store the context object in memory or in a database so that it can be quickly retrieved when a new order status flow request is received.

[0107] In this embodiment, regarding step S2: obtaining a processor:

[0108] Specifically, obtain order information (S200): when a new order status transfer request is received (such as a user calling a car through an APP), parse the order ID and current status (such as pending orders) in the request.

[0109] Based on the order ID, get all the information related to the order from the context.

[0110] Specifically, search for a processor (S201): search for a corresponding processor in a processor mapping table according to the order status (such as pending orders), events (such as user calling a car) and channel information (such as APP) in the context.

[0111] Call the data preparation method of the found processor to prepare all the data required to execute the state flow (such as user information, driver information, etc.).

[0112] In this embodiment, regarding step S3: the processor executes:

[0113] Specifically, determine the next state and execute business logic: In the processor, based on the current state (such as pending orders) and events (such as user calling a car), call the method to obtain the next state and determine the next state (such as in progress).

[0114] Call the business logic execution (action) method of the processor to execute the core business logic of state flow, such as updating order information (updating the order status from pending order to in progress) and calculating the cost (calculating the estimated cost based on the travel distance and time).

[0115] In this embodiment, regarding step S4: the processor executes (continued)

[0116] Specifically, data persistence (S400): before or after data persistence, load and execute relevant data verification and data conversion plug-ins to ensure the correctness and consistency of data. Call the data persistence (save) method of the processor to persist the results of the state flow (such as new order status, cost information, etc.) into the database.

[0117] Specifically, execute the subsequent processing logic (S401): after the data persistence is completed, call the subsequent processing (after) method of the processor to execute the subsequent processing logic after the state flow, such as sending notifications (SMS, emails) to users and drivers, updating the order status in the cache, etc.

[0118] Specifically, asynchronously sending an event notification (S402): after the processor completes execution, preparing relevant information of the event notification (such as order ID, state change, timestamp, etc.).

[0119] The event notification information is sent to the background message queue or event bus, which is asynchronously processed by a dedicated notification component and sent to related systems or users (such as updating the order status of the user's APP interface).

[0120] In this embodiment, regarding step S5: order status flow ends / enters loop

[0121] Specifically, the order status is updated to the final status (S500): if the order status flow ends (such as the order is completed), the order status field in the database is modified and the order status in the cache is updated.

[0122] After completing the status update, the order status transfer process ends and resources are released.

[0123] Specifically, the order status is set to a waiting status (S501): If the order status flow needs to enter the next cycle (such as waiting for user payment, waiting for the driver to arrive, etc.), the order status is set to a certain waiting status (such as waiting for payment), and the waiting event type (such as payment event) and the timeout waiting information are saved.

[0124] Specifically, wait for the next event to be triggered (S502): set an event listener to listen to the next event related to the order (such as a user payment event, a driver arrival event, etc.).

[0125] While waiting for an event to be triggered, keep the order status in a waiting state and prepare the data and logic required to process the next event.

[0126] When the next event is triggered, the corresponding processing logic is executed according to the event type and business logic, and step S2 is restarted for a new round of state flow.

[0127] In this solution, by introducing the concept of state machine, the complex order state conversion process is decomposed into a series of clear states and events, making the state definition and conversion rules clearer and more specific. This helps reduce the complexity of business logic and improve the maintainability and scalability of the code.

[0128] Moreover, the state machine engine ensures that each state transition is atomic, that is, it is either fully executed or not executed at all, thus avoiding data inconsistency problems during the state transition process. In addition, by loading and executing related plug-ins (such as data verification, data conversion, etc.), the correctness and consistency of data during the state transition process can be further ensured.

[0129] The state machine makes the business logic clearer and more modular, making it easier to develop and maintain. By adding new states and events, the system's functionality can be easily expanded without extensive modifications to existing code. By asynchronously sending event notifications and updating the order status of the user interface, changes in order status can be fed back to users in real time, improving user experience and satisfaction.

[0130] Embodiment 2: This embodiment will further provide a Python execution program of the solution described in Embodiment 1:

[0131]

[0132]

[0133]

[0134]

[0135]

[0136] In the above program, the configuration file is loaded when the state machine engine (StateMachineEngine) is initialized, including states, events, and state transition rules. Methods for registering processors, getting processors, creating contexts, and getting contexts are provided.

[0137] The processor contains methods for data preparation, obtaining the next state, executing business logic, data persistence, and subsequent processing. It determines the next state based on the current state and events, and executes the corresponding business logic.

[0138] The context stores all relevant information during the order status flow, including order ID, current status, events, and channel information. During the state flow, the context object is passed to the processor so that the processor can access and modify relevant information.

[0139] The process execution is:

[0140] Initialize the state machine engine and register the handler.

[0141] Create a context object to store order information.

[0142] When a new order status flow request is received, the order ID, current status, event and channel information in the request are parsed and the context is updated.

[0143] According to the information in the context, the corresponding processor is found in the processor mapping table, and its method is called to execute the state flow.

[0144] After the execution is completed, the order status is updated to the final status or set to the waiting status and wait for the next event to be triggered.

[0145] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0146] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0147] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A general order state machine based on multiple categories of SAAS platform, characterized by: When receiving the input order state machine solution activation instruction, initializing the state machine engine and registering the processor, perform the following steps: S1, scans and registers processors, and builds a processor mapping table based on the dimensions of multi-state, multi-channel, and multi-event; when a new order status flow request is received, relevant information is obtained from the context based on the order ID and current status in the request; S2, obtain the corresponding processor from the processor mapping table; Call the data preparation method of the processor to prepare the data required for the execution state flow; S3, call the processor's get next state method to determine the next state based on the current state and events; call the processor's business logic execution method to execute the core business logic of state transfer; S4, call the data persistence method of the processor to persist the result of the state flow to the database; call the subsequent processing method of the processor to execute the subsequent processing logic after the state flow.

2. The universal order state machine according to claim 1, characterized in that: The execution process of S1 includes: S100, read and parse the configuration file of the state machine engine, including the initialization parameters, state definition, event definition and state transition rules of the state machine engine; initialize the running environment of the state machine engine according to the parameters in the configuration file, including the creation of the state machine instance, the initialization of the state list and the setting of the event listener S101, scanning the processor classes in the system according to the dimensions of multi-state, multi-channel and multi-event; registering the scanned processor classes into the state machine engine, and building a processor mapping table according to the state, event and channel information supported by the processor classes; S102, create a context object for each order to store all relevant information during the order status flow, including order ID, current status, events and channel information; store the context object in memory or in a database.

3. The universal order state machine according to claim 1, characterized in that: The execution process of S2 includes: S200, when a new order status transfer request is received, the order ID and current status in the request are parsed; according to the order ID, all information related to the order is obtained from the context, including order status, events, and channel information; S201, according to the order status, event and channel information in the context, find the corresponding processor in the processor mapping table; call the data preparation method of the found processor to prepare all the data required for the execution state flow.

4. The universal order state machine according to claim 1, characterized in that: In S3, in the processor, according to the current state and event, a method for obtaining the next state is called; Call the processor's business logic execution method, including updating order information and calculating fees.

5. The universal order state machine according to claim 1, characterized in that: In said S4, the subsequent processing logic after the state transfer is executed, including sending notifications and updating cache; After the processor is executed, the background sends an event notification asynchronously to notify the component of the change in order status.

6. The universal order state machine according to claim 5, characterized in that: The execution process of S4 includes: S400, before or after data persistence, load and execute relevant data verification and data conversion plug-ins; S401, after data persistence is completed, calling the subsequent processing method of the processor, the subsequent processing method is the subsequent processing logic after the state flow, including sending notifications and updating cache; S402, after the processor completes execution, prepares relevant information of the event notification, including the order ID, status change and timestamp; sends the event notification information to the background message queue or event bus, asynchronously processes and sends notifications to related systems or users.

7. The universal order state machine according to claim 1, characterized in that: Also includes S5: If the order status transfer is completed, update the order status to the final status and end this process; If the order status flow needs to enter the next cycle (such as waiting for user operation, waiting for external system response, etc.), the order status is set to the waiting state and waits for the next event to be triggered.

8. The universal order state machine according to claim 7, characterized in that: The execution process of S5 includes: S500, if the order status transfer is completed, modify the order status field in the database and update the order status in the cache; after the status update is completed, end the order status transfer process and release resources; S501, setting the order status to a confirmed waiting status, and saving the waiting information of the waiting event type and the timeout period; S502, setting an event listener to listen to the next event related to the order, including user operation events and external system response events; While waiting for an event to be triggered, keep the order status in the waiting state and prepare the data and logic required to process the next event; When the next event is triggered, step S2 is restarted.

9. A system for implementing the universal order state machine according to any one of claims 1 to 8, characterized in that: The system comprises: Responsible for loading the state machine engine configuration file and initializing the system initialization module of the state machine engine environment; Order status flow processing module for order status conversion; After the processor is executed, an event notification is sent asynchronously to notify the event notification and status update module of the change in the order status of the relevant components.

10. The system according to claim 9, characterized in that: The order status flow processing module includes: According to the order status, event and channel information in the context, an acquisition processor submodule obtains the corresponding processor from the processor mapping table; Responsible for calling the processor's get next state method and determining the processor execution submodule of the next state.

Images