Method and related device for realizing API connection based on custom domain event

Abstract

The application relates to a method for realizing API connection based on a self-defined domain event and a related device, which comprises the following steps: API interface information and condition rules for triggering API calling are preconfigured in a database; when a business service executes a business operation, an event is generated in a database transaction bearing the business operation and is stored in an event flow table; then, the event is read by a first background process, and matching is performed according to preset condition rules; if the matching is successful, a corresponding calling message is generated in a message flow table; finally, the message is read by a second background process to perform API calling, and messages failing in calling are reserved for subsequent retry. The application realizes dynamic configuration of API connection logic, significantly improves the flexibility of a business, and ensures the consistency and reliability of data synchronization through transaction guarantee and two-stage asynchronous processing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservices, and in particular to a method for realizing API connection based on custom domain events and a related device. BACKGROUND

[0002] In the field of modern software engineering, microservice architecture has become one of the mainstream modes for building complex enterprise-level applications. This architecture divides a single, large application into a group of small, loosely coupled services, so that each service can be developed, deployed and expanded independently, thereby improving the agility of development and the maintainability of the system.

[0003] In the microservice system, communication and data synchronization between each independent service unit are inevitable in order to coordinate the completion of the complete business process. In order to maintain the core advantages of microservice architecture, namely the independence and stability of services, the industry generally adopts an event-driven asynchronous communication mode to replace the tightly coupled direct remote procedure call.

[0004] Among them, the domain event mode is a widely used specific implementation. Domain events refer to objective facts that occur in a specific business domain and have business value, such as "order paid" or "user registered". When a microservice completes a business operation, it publishes a corresponding domain event instead of directly instructing other services to perform operations. Other microservices interested in the event can subscribe to the event and trigger their own business logic according to the event content. By introducing this event-based processing mechanism, the coupling between services can be effectively reduced, and the overall stability and flexibility of the system can be guaranteed. Within a single service, this mode can provide a foundation for data consistency and traceability.

[0005] However, in the practice of the prior art, when a service needs to synchronize data to another service, the target API address of the call, the condition for triggering the call, etc. are usually hard-coded in the program code. Once the business requirements change, for example, a new external system needs to be synchronized, or the synchronization triggering condition needs to be modified, the developer must modify the code, test and redeploy the service. This results in slow response to business changes and increases development costs. At the same time, this also manifests itself in some implementations of event-driven architecture, where the event processing mechanism is globally shared, or the event definitions between services are dependent. If the event mechanism of a service is problematic, it may affect other services. SUMMARY

[0006] The application provides a method for realizing API connection based on a self-defined domain event and a related device, to ensure the independence, stability and decoupling from other services of a service by establishing a specific data table structure and processing logic inside each microservice, and to provide guarantee for the consistency and traceability of data in the same jvm.

[0007] In a first aspect, the application provides a method for realizing API connection based on a self-defined domain event, which adopts the following technical solution:

[0008] A method for realizing API connection based on a self-defined domain event, comprising the following steps:

[0009] A configuration step: an API configuration table and an API trigger condition configuration table are pre-configured in a database of a data generation end; the API configuration table is used to store API interface information of an external service; the API trigger condition configuration table is associated with the API configuration table and is used to define condition rules required to trigger API calling;

[0010] An event generation step: when a business service of the data generation end executes a business operation, an event is generated according to business data of the business operation in a database transaction carrying the business operation, and the event is stored in an event flow table;

[0011] An event processing and message generation step: a first background process reads the event from the event flow table; the first background process matches condition rules in the API trigger condition configuration table according to business data of the event, to determine one or more to-be-called APIs meeting the conditions; if the matching is successful, the first background process generates one or more corresponding messages in a message flow table according to the event and the to-be-called API, and moves the event from the event flow table to an event flow backup table;

[0012] A message execution step: a second background process reads the message from the message flow table; the second background process acquires corresponding API interface information from the API configuration table according to the message and initiates API calling;

[0013] A reliability guarantee step: if the API calling is successful, the message is moved from the message flow table to a message flow backup table; if the API calling fails, the message is retained in the message flow table for subsequent retry calling.

[0014] By adopting the technical scheme, the application decouples the business logic of API interfacing from the program code, and realizes the configuration management of the data synchronization logic by configuring the API interface information and the trigger condition rules in the database. When the business requirement changes, for example, a new external service needs to be interfaced or the trigger condition of data synchronization needs to be modified, only the data of the corresponding configuration table needs to be added, deleted or modified in the database, without modifying, compiling and redeploying the service code. This greatly improves the business flexibility and scalability of the system, significantly shortens the time required to respond to business changes, and effectively reduces the development and maintenance cost in the later stage.

[0015] The application fundamentally guarantees the strong consistency of the business state and the event state by placing the generation operation of the event and the business data processing operation in the same database transaction and using the atomicity feature of the database. The scheme can effectively prevent the inconsistent situation that the business operation is successful but the event is lost, or the business operation fails but the event has been sent, and ensures the accuracy of the event source and the data integrity.

[0016] Furthermore, the application adopts a two-stage asynchronous processing mechanism, and completely decouples the business processing of the data generation end and the API calling of the data receiving end by taking the event flow table and the message flow table as persistent buffers. When the external service has a temporary fault or network interruption, the API calling task to be executed is safely retained in the message flow table, and the data can finally be successfully sent through the retry mechanism, so that high-availability data synchronization is realized, data loss or service blocking caused by local faults is effectively avoided, and the robustness and stability of the entire micro-service system are enhanced.

[0017] Optionally, the condition rules in the API trigger condition configuration table include an event type, a condition field and an operator.

[0018] In the event processing and message generation step, the first background process executes the matching according to whether the business data of the event satisfies the logic defined by the event type, the condition field and the operator.

[0019] By adopting the technical scheme, the condition rules are explicitly defined as the combination of the event type, the condition field and the operator, so that the configuration personnel can conveniently construct complex business trigger logic by simply combining the three basic elements, without writing any code or script. This not only greatly enhances the accuracy and flexibility of the configuration, so that the synchronization rules can be more closely matched with the actual business scenario, but also makes the creation and maintenance process of the rules more intuitive and less prone to errors, further improving the usability and maintainability of the system.

[0020] In addition, the standardized rule structure simplifies the matching logic of the background process. The background process only needs to directly compare the field and value of the event data according to the established structure, and the processing path is shorter and the execution efficiency is higher compared with executing a complex custom script. Therefore, the scheme not only improves the configuration flexibility, but also helps to improve the performance of event processing and the throughput of the system, especially in high-concurrency business scenarios.

[0021] Optionally, the configuration step further comprises:

[0022] The API configuration table and the API trigger condition configuration table are configured independently for different business subjects; and when matching the condition rule, the first background process preferentially searches for a condition rule corresponding to a business subject ID of a current business operation, and if not found, searches for a condition rule of a preset default business subject.

[0023] By adopting the above technical scheme, by setting up independent API configurations and condition rules for different business subjects, a unified system can provide services for multiple isolated user groups or customer organizations, thereby effectively supporting a multi-tenant business scenario. This not only ensures the independence and security of the data synchronization logic between different business subjects, prevents cross-influence caused by configuration errors, but also extends the application range of the application from a single system to the field of platform-level or software-level services.

[0024] In addition, the two-level progressive logic of preferentially searching for a business subject exclusive rule and searching for a default rule if not found defined by the scheme takes into account the flexibility and standardization of the configuration. On the one hand, it allows each business subject to be highly customized according to its own special business needs; on the other hand, by setting up default rules, it can deposit general and standardized synchronization logic for all business subjects to share. This design greatly reduces repetitive configuration work, simplifies the management and maintenance of a large number of business subjects, and can quickly provide basic functions when a new business subject is introduced, thereby significantly improving the overall operation efficiency and scalability of the system.

[0025] Optionally, the event generation step comprises:

[0026] The business operation is executed through an entry class method, wherein the entry class method is used to call a business class method for executing business logic, and the event is stored into an event flow table in the same database transaction.

[0027] By adopting the technical scheme, the core business logic code does not need to care about specific details of event generation, and can maintain its original independence and stability. The event publishing logic is converged in the entry class method, and the wrapper design mode effectively reduces the technical implementation risk and cost when the event mechanism of the application is integrated into an existing or complex business system.

[0028] Meanwhile, the standardized entry class method also provides a consistent and reusable programming paradigm for the system. When adding event publishing functions for new business scenarios, developers can follow a unified mode, thereby improving development efficiency, ensuring code quality and system architecture consistency, making the entire application system more modular, and easy to understand and maintain in the long term.

[0029] Optionally, the first background process and the second background process are triggered for execution through an asynchronous queue in memory.

[0030] In the event processing and message generation step, the event is stored in the first asynchronous queue, and the first background process takes the event from the first asynchronous queue and processes it.

[0031] In the message execution step, the generated message is stored in the second asynchronous queue, and the second background process takes the message from the second asynchronous queue and initiates an API call.

[0032] In a second aspect, the application provides a device for implementing API docking based on a custom domain event, which adopts the following technical scheme:

[0033] A device for implementing API docking based on a custom domain event, comprising:

[0034] A configuration module is configured to pre-configure an API configuration table and an API trigger condition configuration table in a database of a data generation end. The API configuration table is used to store API interface information of an external service. The API trigger condition configuration table is associated with the API configuration table and is used to define condition rules required to trigger an API call.

[0035] An event generation module is configured to generate an event according to business data of a business operation when a business service of the data generation end executes the business operation, and store the event in an event flow table within a database transaction carrying the business operation.

[0036] An event processing and message generation module is configured to read the events from the event flow table by a first background process; the first background process matches the condition rules in the API trigger condition configuration table according to the business data of the events to determine one or more to-be-invoked APIs that meet the conditions; if the matching is successful, the first background process generates one or more corresponding messages in the message flow table according to the events and the to-be-invoked APIs, and moves the events from the event flow table to the event flow backup table;

[0037] A message execution module is configured to read the messages from the message flow table by a second background process; the second background process acquires the corresponding API interface information from the API configuration table according to the messages and initiates API calling;

[0038] A reliability guarantee module is configured to move the messages from the message flow table to the message flow backup table if the API calling is successful, and retain the messages in the message flow table for subsequent retry calling if the API calling fails.

[0039] In a third aspect, a computer device is provided, which adopts the technical scheme as follows:

[0040] A computer device includes:

[0041] one or more processors;

[0042] a memory;

[0043] one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to:

[0044] execute the method for realizing API connection based on the custom domain events as described above.

[0045] In a fourth aspect, a computer readable storage medium is provided, which adopts the technical scheme as follows:

[0046] A computer readable storage medium stores a computer program capable of being loaded and executed by a processor to execute the method as described above.

[0047] The storage medium stores at least one instruction, at least one program, a code set or an instruction set, which are loaded and executed by the processor to realize:

[0048] the method for realizing API connection based on the custom domain events as described above. BRIEF DESCRIPTION OF DRAWINGS

[0049] Figure 1 A program block diagram of a method for realizing API connection based on a self-defined domain event in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0050] The present application will be further described below in conjunction with the drawings. It should be understood that the specific embodiments described herein are intended to be merely exemplary of the application and not intended to limit the application.

[0051] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the inventive concept. As part of the present disclosure, some of the drawings included herein are presented in block diagram form to avoid obscuring the disclosed principles. Some features of actual implementations can not be described in detail to not unnecessarily obscure the inventive subject matter. Also, the language used in the present disclosure has been principally selected for readability and instructional purposes and can not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. References in the present disclosure to "one implementation" or "an implementation" means that a particular feature, structure, or characteristic described is included in at least one implementation, and multiple references to "one implementation" or "an implementation" do not necessarily all refer to the same implementation.

[0052] The terms "a," "an," and "the" are not intended to refer to singular entities, but include the general class of which a specific example can be used for illustration. The use of the terms "a" or "an" can mean any number of including "one," "one or more," "at least one," and "one or more than one." The term "or" means any one of the alternatives, as well as any combination of the alternatives, including all of the alternatives, unless the alternatives are expressly indicated to be mutually exclusive. The phrase "at least one of" followed by a list of items means any individual item in the list, as well as any combination of items in the list, unless expressly indicated to the contrary. The phrase "at least one of" followed by a list of items means any individual item in the list, as well as any combination of items in the list, unless expressly indicated to the contrary.

[0053] Reference Figure 1 The present application discloses a method for realizing API connection based on a self-defined domain event, which is realized based on a pre-set database including an API configuration table, an API trigger condition configuration table, an event flow table, an event flow backup table, a message flow table, and a message flow backup table.

[0054] As an example, the following will be described in a specific scenario of a marketing service (pm) as a data generation end. In this scenario, the six tables in the database are specifically pm_channelsend_api table, pm_channelsend_apiconf table, pm_channelsend table, pm_channelsend_bak table, pm_channelsendlist table, and pm_channelsendlistbak table.

[0055] The six tables work together to form the core data structure of the present application. Among them, the API configuration table (pm_channelsend_api) and the API trigger condition configuration table (pm_channelsend_apiconf) jointly undertake the configuration function of the synchronization rule. The API configuration table is used to centrally store the interface definition information of all possible external API calls, such as interface code, interface address, etc. The API trigger condition configuration table corresponds to the API configuration table, and its internal details define the conditions that must be met to trigger a specific API call, for example, a specific field of a business object can be configured to meet a specific logical relationship, and then trigger the corresponding API call.

[0056] The event flow table (pm_channelsend) and the event flow backup table (pm_channelsend_bak) are responsible for recording the life cycle of the original domain event. The event flow table serves as the entrance of the event, and is used to persistently record the generation of the event in a transactional manner when a business operation occurs. Its content includes the original business data of the triggering event. When an event is successfully processed by the subsequent process and generates a corresponding to-be-executed message, the event record will be removed from the event flow table and stored in the event flow backup table (pm_channelsend_bak) for subsequent audit and traceability.

[0057] The message flow table (pm_channelsendlist) and the message flow backup table (pm_channelsendlistbak) are responsible for managing the to-be-executed API call tasks. The message flow table is a specific API call instruction list generated after the event in the event flow table and the rule in the API trigger condition configuration table are successfully matched. Only the tasks recorded in this table will trigger the call to the external service. When an API call instruction is successfully executed, the record will be removed from the message flow table and stored in the message flow backup table (pm_channelsendlistbak).

[0058] The data flow path of the whole scheme is: events are generated in the event flow table, and after processing, they are archived to the event flow backup table; messages generated by events are created in the message flow table, and after successful execution, they are archived to the message flow backup table.

[0059] Specifically, the method for realizing API connection based on custom domain events includes a configuration step, an event generation step, an event processing and message generation step, a message execution step, and a reliability guarantee step. Firstly, through the configuration step, the synchronization logic of API connection is solidified in the form of data in the database table, thereby realizing the dynamic configuration of the synchronization rule to improve the business flexibility. Secondly, through the event generation step, the creation of events and business operations are bundled in the same database transaction to ensure the state consistency of business data and event data. Furthermore, by separating the event recognition matching and the final API call execution into two independent asynchronous background processes, and using the message flow table as a persistent task buffer, the data generation end and the data receiving end are effectively decoupled, and through the failure retry mechanism in the reliability guarantee step, the reliability and high availability of data synchronization are ensured. The specific implementation of each step will be described in detail later.

[0060] The configuration step: in the database of the data generation end, an API configuration table and an API trigger condition configuration table are pre-configured; the API configuration table is used to store API interface information of external services; the API trigger condition configuration table is associated with the API configuration table and is used to define the condition rules required to trigger API calls.

[0061] The reason why the API interface information and the trigger condition rules are stored in two independent tables in this scheme is to solve the technical problems of configuration redundancy and maintenance difficulty caused by the many-to-many relationship between API interfaces and trigger conditions in complex business scenarios. In actual application, the same API interface may need to be triggered by multiple different business events or conditions, and vice versa, the same business event may need to trigger multiple different API calls. If the interface information and the condition rules are coupled and defined together, when the API interface information used in multiple places is changed, all the rules that reference the interface need to be modified, which not only is cumbersome to operate and easy to miss, but also greatly increases the maintenance cost.

[0062] The embodiments of the present application realize the reuse of API interface definition by separating the two. The API configuration table is a registration center of all available external interfaces in the system, each interface has its unique interface code, and is defined once. The API trigger condition configuration table establishes the association with the specific API interface by referencing the interface code. This design forms a one-to-many mapping structure: one record in the API configuration table can be referenced by multiple different rules in the API trigger condition configuration table. In this way, when the API interface information changes, only one record in the API configuration table needs to be modified, and all trigger rules that reference the interface will automatically take effect, thereby greatly simplifying the maintenance work of the system.

[0063] Taking a marketing service as an example, it is assumed that the system needs to be connected with an external activity management system and a message notification system. At this time, two interfaces can be defined in the API configuration table (pm_channelsend_api): one is an activity creation interface, and the interface code is CAMP_CREATE; the other is a message sending interface, and the interface code is NOTIFY_SEND. In the API trigger condition configuration table (pm_channelsend_apiconf), multiple rules can be created to call the two interfaces respectively or in combination. For example, a rule can be configured to trigger the call of the CAMP_CREATE interface when a marketing activity of a discount coupon type is created; at the same time, another rule can be configured to trigger the call of the NOTIFY_SEND interface to notify the user when the state of the marketing activity is manually updated to activated. In addition, if the system also needs to update the marketing activity information to the external activity management system when the marketing activity information is modified, only one more trigger condition needs to be added to point to the existing CAMP_CREATE interface, without the need to repeatedly define the detailed information of the interface.

[0064] An event generation step: when a business service of a data generation end executes a business operation, an event is generated according to business data of the business operation in a database transaction carrying the business operation, and the event is stored in an event flow table.

[0065] The data generation end refers to the initiator of business behavior and the producer of original data in the micro-service architecture, which is the marketing service in the embodiment. The business service executes a business operation, which means that the application program of the data generation end has executed an action with a clear business meaning, such as creating a new coupon, updating the state of a marketing activity, etc., which will cause the state change of the system data. The event is an objective record of the state change of the system when the business operation is completed, which usually contains the key business data of the operation as a factual notification for subsequent process.

[0066] The step places the storage operation of the event and the business operation itself in the same database transaction, which refers to a series of operations that are regarded as a single logical work unit and have atomicity, that is, all operations in the transaction are executed successfully or are all failed to be rolled back, and there is no case of partial execution success. The purpose of this design is to fundamentally guarantee the consistency of data. By using the atomicity of the database transaction, it is ensured that the modification operation on the business data table and the write operation on the event stream table become an indivisible whole. In this way, the case that the business data is successfully saved but the event is not sent out, or the case that the business operation is failed to be rolled back but the event is sent out can be completely avoided when the system abnormally occurs.

[0067] Taking a marketing service as an example, in one specific embodiment of the present application, when a user creates a new discount coupon type marketing activity through an interface, the business background of the marketing service will execute a save operation. The save operation will first start a database transaction. In the transaction, the system first executes a first SQL instruction to insert the detailed information of the discount coupon, such as the activity name, the discount amount, the valid period, etc., into the business data table of the marketing activity. Then, the system constructs an event object according to the business data just inserted, and the data content of the object can include the activity ID, the activity type, etc., and the event type can be defined as PROMO_CREATED. Then, the system executes a second SQL instruction to store the serialized event object in the event stream table (pm_channelsend). Finally, the system commits the database transaction. If both insertion operations are successful, the transaction is committed, and the marketing activity and the corresponding creation event are both persistently saved; if any of the operations fails, the entire transaction will be rolled back, and the database is restored to the state before the operation.

[0068] Event processing and message generation step: the first background process reads the event from the event stream table; the first background process matches the condition rules in the API trigger condition configuration table according to the business data of the event, to determine one or more API to be called that meet the conditions; if the matching is successful, the first background process generates one or more corresponding messages in the message stream table according to the event and the API to be called, and moves the event from the event stream table to the event stream backup table.

[0069] The background processing flow is divided into a first background process and a second background process, which can realize complete decoupling of the core business logic and external network communication, thereby improving the stability and maintainability of the system. The responsibility of the first background process is to process internal and deterministic business rule matching, which converts an occurred business fact (event) into one or more to-be-executed technical actions (messages). The responsibility of the second background process is focused on executing the technical actions, i.e., communicating with external services, and processing various abnormal situations such as network delay and service unavailability caused thereby. Through such responsibility separation, even if the external service has a long-time fault, causing the second background process to repeatedly retry, it will not block the continuous processing of the first background process on new events, thereby realizing fault isolation.

[0070] This step interprets the determined event according to the business rules in the configuration step, and generates corresponding API call instructions. After the step is successfully executed, the original event can be archived. In the above example, after the creation event of the activity is stored in the event flow table (pm_channelsend), the first background process reads the record. The process first parses the event type as PROMO_CREATED, and learns from the business data of the event that the type of the activity is a discount coupon. Then, the first background process finds all corresponding condition rules in the API trigger condition configuration table (pm_channelsend_apiconf) according to the event type. It will find the aforementioned configured rule, i.e., when a marketing activity of the type of discount coupon is created, the call of the CAMP_CREATE interface is triggered. The process compares the event data with the conditions of the rule, and determines that the condition is established. Therefore, the first background process will construct an API request body for calling the external activity management system according to the event data and the definition of the CAMP_CREATE interface, and insert a new message record in the message flow table (pm_channelsendlist), which contains the interface code CAMP_CREATE and the to-be-sent request body data. After the message record is successfully inserted, the first background process immediately moves the original event record from the pm_channelsend table to the pm_channelsend_bak table.

[0071] The message execution step: the second background process reads the message from the message flow table; the second background process acquires the corresponding API interface information from the API configuration table according to the message and initiates API call.

[0072] The message execution step processes the pending tasks in the message flow table generated by the first background process and converts these message instructions into actual network calls to external services. By handing over this execution action to a separate second background process, the system is able to isolate the complex, uncertain external communication tasks from the internal business rule processing tasks.

[0073] Continuing with the example, after the first background process successfully generates a message for the CAMP_CREATE interface in the message flow table (pm_channelsendlist), the second background process reads the message record. The process first extracts the interface code CAMP_CREATE and the pre-built API request body data from the message record. Then, the second background process uses the interface code as a query index to find and obtain the complete definition information of the interface in the API configuration table (pm_channelsend_api), such as its corresponding URL address http: / / campaign.service / create. Finally, the second background process uses a HTTP client or other tools to initiate a network request to the obtained URL address and sends the request body data in the message record as a parameter to the external campaign management system.

[0074] Reliability assurance step: if the API call is successful, move the message from the message flow table to the message flow backup table; if the API call fails, keep the message in the message flow table for subsequent retry calls.

[0075] This step judges the result of the API call initiated by the second background process and binds this judgment result with the lifecycle management of the record in the message flow table. If the call is successful, the task is marked as finally completed by removing the message record from the message flow table and archiving it to the backup table, thereby avoiding repeated sending of the message. Conversely, if the call fails, no processing is performed on the message record, which continues to be retained in the message flow table. Since the background process periodically scans or is notified to process the tasks in the table, this unremoved message record will be automatically picked up and retried at a later time point until the call is successful.

[0076] Continuing with the above example, there are two scenarios when the second background process initiates an API call to the external campaign management system. The first scenario is that the call is successful, and the external system returns a status code indicating success, such as HTTP 200. In this case, upon receiving the successful response, the second background process performs a database operation to delete the message record corresponding to the CAMP_CREATE interface from the message flow table (pm_channelsendlist) and store it in the message flow backup table (pm_channelsendlistbak), and the life cycle of the message ends.

[0077] The second scenario is that the call fails, for example, the external system returns a status code indicating that the service is unavailable due to temporary overload or maintenance, or the connection times out due to network problems. In this case, upon catching the exception or response indicating that the call has failed, the second background process does not perform any operation on the message record in the message flow table (pm_channelsendlist). Therefore, the record continues to exist in the table. After a preset delay period, the polling mechanism of the second background process discovers the unprocessed message again and re-executes the previous message execution step, i.e., attempts to initiate an API call again. This retry loop continues until the external system recovers and successfully responds to the API call, thus ensuring that the data synchronization task is not lost due to temporary external failure.

[0078] Specifically, the condition rules in the API trigger condition configuration table are composed of elements such as event type, condition field, and operator. Among them, the event type is used to classify business operations, for example, PROMO_CREATED can be used as the type identifier of the marketing campaign creation event; the condition field points to a specific attribute in the business data contained in the event, such as the activity type or the activity amount; and the operator defines the logical judgment that needs to be performed on the condition field, such as equal to, greater than, or less than. In the event processing and message generation step, the first background process performs accurate and item-by-item condition matching on the event data according to this structured definition. Only when all the condition rules associated with a certain API are satisfied, is it determined to be a successful match. This design of atomizing rules allows complex business logic to be constructed by combining simple elements, for example, a specific API call can be triggered when the event type is PROMO_CREATED, the activity type field in the business data of the event is equal to a discount coupon, and the activity amount field is greater than 100, thus achieving high-precision control of the synchronization timing.

[0079] Specifically, the configuration step of the present application can also support a multi-tenant scenario, in which independent API configuration tables and API trigger condition configuration tables are configured for different business subjects. Here, the business subject refers to an independent customer or organization unit that needs to be isolated in terms of data and configuration in a software as a service (SaaS) architecture. When performing condition rule matching, the first background process adopts a hierarchical lookup strategy. For example, the system can configure rules for business subject A (ID: 111) and the default business subject (ID: 00000000) respectively. When an event occurs in the business service of business subject A, the first background process will first use the business subject ID "111" to look up its exclusive condition rules; after looking up and processing the exclusive rules, or if no exclusive rules are found, the process will continue to use the default business subject ID "00000000" to look up general condition rules. This design not only ensures the independence and security of each business subject configuration, but also provides the ability to reuse rules through default configuration, realizes the unification of individualization and standardization, and improves the management efficiency of the system.

[0080] Specifically, the event generation step can perform business operations through an entry class method. Here, the business logic refers to the code implementation in the application for processing specific business rules and processes, and the business class method is the specific code method that carries this business logic. The entry class method is an encapsulation or proxy method that does not implement the core business logic itself, but is responsible for calling the original business class method and uniformly processing cross-cutting concerns such as starting a database transaction, generating an event and storing, committing or rolling back the transaction before and after or inside and outside the call. For example, a marketing service save operation can create an entry class method sendSavePromotion, which internally first starts a transaction, then calls the original business class method savePromotion that is only responsible for storing activity information into the database. After the savePromotion method successfully returns, the sendSavePromotion method immediately performs the operation of storing the event into the event log table within the same transaction, and finally commits the transaction. This mode separates the event publishing logic from the core business logic, reduces the coupling degree of the code, and enables the functions of the present application to be easily integrated into existing systems without the need for extensive modification of the original business class method.

[0081] Specifically, to improve the system response capability and throughput, the first background process and the second background process can be triggered for execution through an asynchronous queue in memory. The asynchronous queue in memory is a data structure for decoupling the delivery of tasks among different threads. In the event processing and message generation step, after the entry class method successfully commits a transaction, the newly generated event ID can be stored in the first asynchronous queue. The independent thread pool responsible for executing the first background process obtains the event ID from the queue and performs subsequent database query and rule matching processing. Similarly, in the message execution step, after the first background process successfully generates one or more messages, the IDs of these messages can be stored in the second asynchronous queue, which is obtained and executed by another independent thread pool responsible for executing the second background process. Through the introduction of the asynchronous queue, the main thread performing the business operation can quickly return after completing the database transaction submission and enqueuing operation, without waiting for the subsequent time-consuming rule matching and network call, thereby significantly reducing the waiting time of the front-end user and improving the concurrent processing capability of the system.

[0082] It should be understood that, in addition to the configuration step, which can be completed in advance before other steps are performed, there is an inherent logical execution order between the event generation step, the event processing and message generation step, the message execution step, and the reliability guarantee step, but the adjustment made by the person skilled in the art to the specific implementation manner or parallel processing of the background process according to the inspiration of the present application should not constitute any limitation on the implementation process of the present application.

[0083] In an embodiment, an apparatus for implementing API connection based on custom domain events is provided, which corresponds to the method for implementing API connection based on custom domain events in the above-mentioned embodiments. The apparatus for implementing API connection based on custom domain events comprises a configuration module, an event generation module, an event processing and message generation module, a message execution module, and a reliability guarantee module. The functions of each module are described in detail as follows:

[0084] The configuration module is configured to pre-configure an API configuration table and an API trigger condition configuration table in a database of a data generation end. The API configuration table is used to store API interface information of an external service. The API trigger condition configuration table is associated with the API configuration table and is used to define condition rules required to trigger API calls.

[0085] The event generation module is configured to generate an event from business data of a business operation when a business service of the data generation end executes the business operation, and store the event in an event flow table within a database transaction carrying the business operation.

[0086] An event processing and message generating module is configured to read the events from the event flow table by a first background process; the first background process matches the condition rules in the API trigger condition configuration table according to the business data of the events to determine one or more to-be-invoked APIs that meet the conditions; if the matching is successful, the first background process generates one or more corresponding messages in the message flow table according to the events and the to-be-invoked APIs, and moves the events from the event flow table to the event flow backup table;

[0087] A message executing module is configured to read the messages from the message flow table by a second background process; the second background process acquires the corresponding API interface information from the API configuration table according to the messages and initiates API calling;

[0088] A reliability guarantee module is configured to move the messages from the message flow table to the message flow backup table if the API calling is successful, and retain the messages in the message flow table for subsequent retry calling if the API calling fails.

[0089] The specific limitations of the device for implementing API connection based on custom domain events can be referred to the limitations of the method for implementing API connection based on custom domain events, which will not be repeated here. Each module in the device for implementing API connection based on custom domain events can be realized by software, hardware and their combinations. Each module can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory in the computer device in software form, so as to call and execute the operations corresponding to each module by the processor.

[0090] In an embodiment, a computer device is provided, which can be a server. The computer device includes a processor, a memory, a network interface and a database connected by a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store data related to the method for implementing API connection based on custom domain events. The network interface of the computer device is configured to communicate with external terminals through network connection. The computer program is executed by the processor to implement a method for implementing API connection based on custom domain events.

[0091] In an embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the method for API connection based on the custom domain event in the above embodiment when executing the computer program. Alternatively, the processor implements the functions of each module / unit of the device for API connection based on the custom domain event in the above embodiment when executing the computer program. To avoid repetition, details are not described here.

[0092] In an embodiment, a computer readable storage medium is provided, having a computer program stored thereon, and the computer program is executable on a processor to implement the method for API connection based on the custom domain event in the above embodiment. Alternatively, the computer program is executable on the processor to implement the functions of each module / unit of the device for API connection based on the custom domain event in the above embodiment. To avoid repetition, details are not described here.

[0093] A person of ordinary skill in the art can understand that all or part of the processes in the above embodiments can be completed by a computer program instructing related hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above embodiments can be included. Any reference to memory, storage, database or other medium in the embodiments of the present application 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 but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct RAM bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0094] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual application, the above functions can be completed by different functional units and modules according to needs, i.e. the internal structure of the device is divided into different functional units or modules to complete all or part of the above described functions.

[0095] The above examples are only used to illustrate the technical solutions of the present application, but not limit the present application; although the present application has been described in detail with reference to the foregoing examples, those ordinarily skilled in the art should understand: the technical solutions recorded in the foregoing examples can still be modified, or some technical features can be replaced equivalently; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for API integration based on custom domain events, characterized in that, Includes the following steps: Configuration steps: In the database of the data generation end, pre-configure the API configuration table and the API trigger condition configuration table; wherein, the API configuration table is used to store the API interface information of external services; the API trigger condition configuration table is associated with the API configuration table and is used to define the condition rules that need to be met to trigger API calls; Event generation steps: When the business service at the data generation end executes a business operation, within the database transaction carrying the business operation, an event is generated based on the business data of the business operation, and the event is stored in the event log table; Event processing and message generation steps: The first background process reads the event from the event flow table; the first background process matches the business data of the event with the condition rules in the API trigger condition configuration table to determine one or more APIs to be called that meet the conditions; if the match is successful, the first background process generates one or more corresponding messages in the message flow table based on the event and the API to be called, and moves the event from the event flow table to the event flow backup table; Message execution steps: The second background process reads the message from the message flow table; the second background process obtains the corresponding API interface information from the API configuration table based on the message and initiates an API call; Reliability assurance steps: If the API call is successful, the message is moved from the message flow table to the message flow backup table; if the API call fails, the message is retained in the message flow table for subsequent retry calls.

2. The method for API integration based on custom domain events according to claim 1, characterized in that, The condition rules in the API trigger condition configuration table include: event type, condition field, and operator; In the event processing and message generation steps, the first background process performs the matching based on whether the business data of the event meets the logic jointly defined by the event type, condition fields, and operators.

3. The method for API integration based on custom domain events according to claim 1 or 2, characterized in that, The configuration steps also include: Configure independent API configuration tables and API trigger condition configuration tables for different business entities; and when the first background process matches condition rules, it first searches for condition rules corresponding to the business entity ID of the current business operation. If no such rule is found, it searches for the condition rules of the preset default business entity.

4. The method for API integration based on custom domain events according to claim 1, characterized in that, The event generation steps include: The business operation is executed through an entry class method, wherein the entry class method is used to call the business class method that executes the business logic, and the event is stored in the event log table within the same database transaction.

5. The method for API integration based on custom domain events according to claim 1, characterized in that, The first and second background processes are triggered to execute through an asynchronous queue in memory; In the event processing and message generation steps, the event is stored in the first asynchronous queue, and the first background process retrieves the event from the first asynchronous queue and processes it. In the message execution step, the generated message is stored in the second asynchronous queue, and the second background process retrieves the message from the second asynchronous queue and initiates an API call.

6. A device for API integration based on custom domain events, characterized in that, include: The configuration module is used to pre-configure an API configuration table and an API trigger condition configuration table in the database of the data generation end; wherein, the API configuration table is used to store API interface information of external services; the API trigger condition configuration table is associated with the API configuration table and is used to define the condition rules that need to be met to trigger API calls; The event generation module is used to generate an event based on the business data of the business operation within the database transaction carrying the business operation when the business service of the data generation end performs a business operation, and store the event in the event log table. The event processing and message generation module is used by a first background process to read the event from the event flow table; the first background process matches the business data of the event with the condition rules in the API trigger condition configuration table to determine one or more APIs to be called that meet the conditions; if the match is successful, the first background process generates one or more corresponding messages in the message flow table according to the event and the API to be called, and moves the event from the event flow table to the event flow backup table; The message execution module is used by the second background process to read the message from the message flow table; the second background process obtains the corresponding API interface information from the API configuration table according to the message and initiates an API call; The reliability assurance module is used to move the message from the message flow table to the message flow backup table if the API call is successful; if the API call fails, the message is retained in the message flow table for subsequent retry calls.

7. A computer device, characterized in that, It includes: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to: execute the method for implementing API integration based on custom domain events as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement: the method for API integration based on custom domain events as described in any one of claims 1 to 5.

Images