Business event processing method, business system, device and storage medium

Abstract

The invention discloses a business event processing method, a business system, a business event processing device and a storage medium, which are used for realizing loose coupling among multiple systems. The business event processing method comprises the following steps: asynchronously consuming financial event messages in a preset message queue; preprocessing the financial event message to obtain a processing result; according to the business event type, the financial context object is routed to a corresponding scene converter, so that the scene converter processes the financial context object, and an enhanced context object is obtained; according to the business data field features, the enhanced context object is routed to a corresponding adaptive converter, so that the adaptive converter processes the enhanced context object, and a financial registration request instruction is obtained; in response to the financial registration request instruction, generating an accounting entry document; and calling a corresponding external system interface according to the accounting entry document, so that an external system responds to the financial event message.

Description

Technical Field

[0001] This application relates to the field of financial information processing technology, and in particular to a method, system, electronic device, and storage medium for processing business events. Background Technology

[0002] In traditional financial management systems, business systems and financial systems typically interact using a tightly integrated architecture. Specifically, when a business system generates a transaction that requires financial recording, it directly calls the application programming interface (API) exposed by the financial system to trigger the financial processing flow. That is, the business system initiates a financial processing request in real time by calling the service interface of the financial system through methods such as remote procedure calls or hypertext transfer protocol requests. After the financial system completes data verification, voucher generation, and account updates, it synchronously returns the processing results to the business system, thereby achieving closed-loop processing of financial events.

[0003] However, in the above methods, a failure in a single system can spread rapidly through the direct call chain, making the reliability of the entire business processing chain dependent on its weakest link. That is, when the financial system experiences service interruption or slow response due to upgrades, failures, or performance pressure, the relevant operation processes of all business systems that depend on its interface will be blocked or fail, the communication link between the two parties will be interrupted, causing widespread business function unavailability and making it impossible to guarantee business continuity. Summary of the Invention

[0004] This application discloses a method, business system, apparatus, and storage medium for processing business events, which are used to achieve loose coupling between multiple systems.

[0005] The first aspect of this application discloses a method for processing business events, applied to a business system, including: Asynchronous consumption of financial event messages in a pre-defined message queue; The financial event message is preprocessed to obtain a processing result, which includes the business event type and the financial context object. Based on the business event type, the financial context object is routed to the corresponding scenario converter, so that the scenario converter can process the financial context object to obtain an enhanced context object, which includes a business module identifier and business data field characteristics. Based on the characteristics of the business data fields, the enhanced context object is routed to the corresponding adapter, so that the adapter can process the enhanced context object and obtain the financial registration request instruction. In response to the financial registration request instruction, generate accounting entries; Based on the accounting entry document, the corresponding external system interface is invoked so that the external system can respond to the financial event message.

[0006] Optionally, the preprocessing of the financial event message to obtain the processing result includes: The financial event message is deserialized to obtain preliminary business data, which includes the business event type. The initial business data is subjected to integrity verification. If the integrity verification passes, a financial context object is constructed based on the initial business data.

[0007] Optionally, after performing integrity verification on the preliminary business data, the method further includes: If the integrity check fails, the steps of asynchronously consuming the financial event messages in the preset message queue and deserializing the financial event messages are executed again. A second integrity check is performed. If the second integrity check fails, the corresponding financial event message is transferred to the dead letter queue and an error log is recorded.

[0008] Optionally, routing the financial context object to the corresponding scenario converter based on the business event type includes: Based on the pre-configured mapping relationship between business event types and scene converter identifiers, a query is performed according to the business event type to obtain the target scene converter identifier; Obtain the corresponding scene converter based on the target scene converter identifier; The financial context object is routed to the corresponding scene converter.

[0009] Optionally, the step of routing the enhanced context object to the corresponding adapter based on the characteristics of the business data field includes: Based on the characteristics of the business data fields, the corresponding business scenario code is obtained through a decision tree algorithm; Based on the business scenario code, query the mapping relationship between the pre-configured scenario code and the adapter identifier to obtain the target adapter identifier; The corresponding adapter is obtained by using the adapter factory class based on the target adapter identifier; The enhanced context object is routed to the corresponding adapter.

[0010] Optionally, obtaining the corresponding business scenario code using a decision tree algorithm based on the characteristics of the business data fields includes: Extract at least one dimension of features from the business data field features, the dimension including event type, funding source, payment channel and / or repayment details structure; Based on a pre-built decision tree model, multi-level condition judgments are performed according to the features of at least one dimension to obtain the judgment result; A business scenario code is generated based on the judgment result.

[0011] Optionally, calling the corresponding external system interface based on the accounting entry document includes: Based on the type of the accounting entry document, the corresponding instruction processor is obtained through the instruction dispatch factory class; The instruction processor generates a request to call the corresponding external system interface based on the accounting entry document. The system responds to the request according to a pre-set retry policy until the corresponding external system interface is successfully invoked.

[0012] The second aspect of this application discloses a business system, including: Asynchronous consumption unit, used for asynchronously consuming financial event messages in a preset message queue; The preprocessing unit is used to preprocess the financial event messages to obtain processing results, which include business event types and financial context objects. The first routing unit is configured to route the financial context object to the corresponding scenario converter according to the business event type, so that the scenario converter can process the financial context object to obtain an enhanced context object, wherein the enhanced context object contains a business module identifier and business data field characteristics; The second routing unit is used to route the enhanced context object to the corresponding adapter converter according to the characteristics of the business data field, so that the adapter converter can process the enhanced context object and obtain the financial registration request instruction. A response unit is used to respond to the financial registration request instruction and generate accounting entry documents; The calling unit is used to call the corresponding external system interface based on the accounting entry document, so that the external system can respond to the financial event message.

[0013] A third aspect of this application provides an apparatus for processing business events, comprising: Processor, memory, input / output units, and bus; The processor is connected to memory, input / output units, and a bus; The memory stores a program, which the processor calls to execute methods such as the first aspect and any optional methods of the first aspect for processing business events.

[0014] The fourth aspect of this application provides a computer-readable storage medium on which a program is stored, which, when executed on a computer, performs a method for processing business events as described in the first aspect and any optional method of the first aspect.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: This application provides a method for processing business events, applied to a business system, including asynchronously consuming financial event messages in a preset message queue; preprocessing the financial event messages to obtain processing results, including a business event type and a financial context object; routing the financial context object to the corresponding scenario converter based on the business event type, so that the scenario converter processes the financial context object to obtain an enhanced context object, which contains a business module identifier and business data field characteristics; routing the enhanced context object to the corresponding adaptation converter based on the business data field characteristics, so that the adaptation converter processes the enhanced context object to obtain a financial registration request instruction; responding to the financial registration request instruction to generate accounting entry documents; and calling the corresponding external system interface based on the accounting entry documents so that the external system responds to the financial event messages. The method for handling business events in this application constructs a loosely coupled interactive architecture by asynchronously consuming financial event messages in a message queue. This allows business systems to complete their processes without waiting for financial processing or external system responses. Even if the financial processing stage or external systems experience upgrades, failures, or slow responses, it will not cause business system operations to be blocked or fail, effectively preventing the spread of faults between systems. Furthermore, the two-level intelligent routing based on business event types and business data characteristics ensures the adaptability and accuracy of financial event processing. This means that when adding new business scenarios, there is no need to modify the core architecture; only the corresponding processors need to be expanded or configured. This solves the problem that business functions are prone to widespread unavailability due to a single system failure under traditional tightly coupled architectures, improving the stability of the business processing chain and ensuring business continuity. Attached Figure Description

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

[0017] Figure 1 A schematic diagram illustrating an embodiment of the method for processing business events according to this application; Figure 2 A schematic diagram of another embodiment of the method for processing business events for this application; Figure 3 A schematic diagram of another embodiment of the method for processing business events for this application; Figure 4 A schematic diagram of another embodiment of the method for processing business events for this application; Figure 5 A schematic diagram of another embodiment of the method for processing business events for this application; Figure 6 This is a schematic diagram of one embodiment of the business system of this application; Figure 7 This is a schematic diagram of one embodiment of the apparatus for processing business events according to this application. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0019] It should be understood that, when used in this application specification, the term "comprising" indicates the presence of the described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0020] It should also be understood that the term “and / or” as used in this application specification means any combination of one or more of the associated listed items, as well as all possible combinations, and includes such combinations.

[0021] As used in this application specification, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0022] Furthermore, in the description of this application, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0024] Based on this, this application discloses a method, business system, apparatus, and storage medium for processing business events, which can achieve loose coupling between multiple systems.

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

[0026] The method described in this application can be applied to servers, devices, terminals, or other devices with logical processing capabilities; therefore, this application does not limit its application. For ease of description, the following description uses a terminal as the executing entity.

[0027] Please see Figure 1 This application provides an embodiment of a method for processing business events, comprising: 101. Asynchronously consume financial event messages in the preset message queue; In this embodiment, the preset message queue is preferably a RocketMQ queue with financial-grade reliability, support for transactional messages, and low latency and high throughput, deployed in a cluster. Alternatively, depending on the actual scenario, a high-throughput Apache Kafka queue, a complex routing-compatible RabbitMQ queue, or a cloud-native Apache Pulsar queue can be selected. Then, a dynamically adjustable thread pool is configured to support asynchronous processing. Message consumption tasks are allocated through a load balancing strategy for consumer groups to ensure efficient collaboration among multiple consumer instances. Simultaneously, message consumption progress persistence and failover mechanisms are enabled. When a consumer instance fails, unprocessed messages from that instance are reassigned to other healthy instances, ensuring the continuity and reliability of message consumption, thereby achieving stable asynchronous consumption of financial event messages in the message queue.

[0028] 102. Preprocess financial event messages to obtain processing results, which include business event type and financial context object; In this embodiment, the financial event message is in JSON format. For subsequent processing steps, this format needs to be preprocessed. Specifically, the financial event message is deserialized into a corresponding Java object to ensure the message data is parsable. Then, data validation is performed to verify the completeness of required fields such as loan amount, customer information, and repayment details, as well as the validity of the data format. Null values ​​and abnormal characters are removed, and the data encoding is standardized. After successful validation, key information such as the business event type and business transaction number are extracted from the parsed object, and a financial context object is constructed. Finally, the processing result, containing the business event type and the financial context object, is output.

[0029] 103. Based on the business event type, route the financial context object to the corresponding scenario converter so that the scenario converter can process the financial context object and obtain an enhanced context object, which contains the business module identifier and business data field characteristics. In this embodiment, the mapping relationship between business event types and corresponding scenario converters is clearly defined. A scenario converter factory class then manages all types of scenario converter instances, and all scenario converters adhere to a unified scenario conversion interface specification. After determining the business event type, the financial context object is automatically routed to the matching scenario converter through a preset mapping relationship and the factory class. Upon receiving the financial context object, the scenario converter first performs data cleaning, standardizes the data format, and completes any missing basic information. Then, based on the processed data, it identifies the business scenario and finally adds business module identifiers and business data field features to the financial context object, forming an enhanced context object.

[0030] 104. Based on the characteristics of the business data fields, route the enhanced context object to the corresponding adapter so that the adapter can process the enhanced context object and obtain the financial registration request instruction; In this embodiment, based on the business data field characteristics in the enhanced context object, a corresponding scene code is generated through a scene recognition algorithm. Routing rules between the scene code and the adapter are established. The adapter factory class is responsible for the routing and instance management of the adapter. Similar to step 103, all adapters follow a unified adapter interface specification. After matching the corresponding adapter based on the business data field characteristics, the adapter first parses the nested structure of the enhanced context object and extracts detailed data from the sub-objects. Then, it loads the corresponding business rule configuration and applies the business rule engine to perform data transformation, including one-to-one field mapping, one-to-many field splitting, and many-to-one field merging, as well as the accounting logic and account mapping rules for interest, principal, and fees. Simultaneously, it performs business logic consistency checks to ensure that the transformed data conforms to financial processing specifications, ultimately generating a standardized financial registration request instruction that can be directly used for financial registration.

[0031] 105. Respond to the financial registration request instruction and generate accounting entry documents; In this embodiment, before responding to the financial registration request instruction, database transaction management should be configured to ensure the atomicity of the persistence of the master order information carried by the financial registration request instruction. Based on the business data and account mapping rules in the financial registration request instruction, combined with the corresponding accounting processing specifications, the corresponding accounting subjects are automatically matched, the debit and credit amounts are calculated, and the debit and credit balance is ensured. At the same time, a state machine is established to manage the lifecycle status of the acceptance form, such as pending registration, registered, and effective, and then the master order information is persisted to the database. Subsequently, the document record layer is linked, and the corresponding document processor is called through the document record factory class. The accounting subject inference algorithm is used to determine the accounting attribution, split and persist the sub-document information, realize the associated storage of master order and sub-document, and finally generate accounting entry documents that conform to accounting specifications and contain complete accounting information.

[0032] 106. Based on the accounting entries, call the corresponding external system interface so that the external system can respond with financial event messages.

[0033] In this embodiment, relying on the instruction dispatch service interface of the instruction dispatch layer, the instruction dispatch factory class matches the corresponding external system instruction processor according to the business type of the accounting entry document. An asynchronous orchestration tool is used to achieve parallel calls to multiple external systems. Simultaneously, a timeout mechanism and retry strategy are configured for each external system call to avoid overall process blockage due to slow response or temporary failure of a single external system. The external systems called include accounting systems, billing systems, etc., and the instruction content includes core accounting entry data, business serial number, and processing requirements. After each external system completes processing and returns a response result, the instruction dispatch layer summarizes all results to form the final processing feedback. If a call fails, a corresponding compensation operation is triggered to ensure business data consistency. Finally, the summarized result is called back to the business system, completing the closed loop of external system response to business event messages.

[0034] It should be noted that the method for handling business events in this embodiment also includes intelligent monitoring and maintenance steps. Specifically, a unique tracking identifier is assigned to each financial event message. This tracking identifier is used throughout the entire processing flow, including message deserialization, integrity verification, scenario converter routing, adaptation converter conversion, accounting entry document generation, and external system interface calls. The processing status and performance indicators of each processing flow are recorded. Furthermore, real-time data on the success, failure, and time consumption of each processing node is collected. Based on this real-time data, periodic health checks are performed on each processing node. When any indicator exceeds a preset threshold, an alarm is triggered.

[0035] In this embodiment, the method for handling business events constructs a loosely coupled interactive architecture by asynchronously consuming financial event messages in the message queue. This allows the business system to complete its own processes without waiting for financial processing or external system responses. Even if the financial processing stage or external system experiences upgrades, failures, or slow responses, it will not cause the business system to be blocked or fail, effectively preventing the spread of faults between systems. Furthermore, the two-level intelligent routing based on business event types and business data characteristics ensures the adaptability and accuracy of financial event processing. This means that when adding new business scenarios, there is no need to modify the core architecture; only the corresponding processors need to be expanded or configured. This solves the problem that business functions under traditional tightly coupled architectures are prone to widespread unavailability due to a single system failure, improving the stability of the business processing chain and ensuring business continuity.

[0036] Please see Figure 2 Step 102 involves preprocessing the financial event message to obtain a processing result. The processing result includes the business event type and the financial context object, which may include, but is not limited to, the following: 201. Deserialize financial event messages to obtain preliminary business data, which includes the business event type; 202. Perform integrity verification on the preliminary business data. If the integrity verification passes, construct a financial context object based on the preliminary business data. 203. If the integrity check fails, repeat the steps of asynchronously consuming the financial event messages in the preset message queue and deserializing the financial event messages; 204. Perform a second integrity check. If the second integrity check fails, transfer the corresponding financial event message to the dead letter queue and record the error log.

[0037] In this embodiment, a JSON deserialization tool is invoked to convert the binary format financial event messages stored in the message queue into corresponding Java objects. This conversion process strictly follows the standardized format definition of the message to ensure accurate field mapping. Subsequently, core information such as business event type, business serial number, and basic business data are extracted from the converted Java objects to form preliminary business data.

[0038] Next, the integrity of the required fields and data formats of the initial business data is validated. Required fields include core business fields such as loan amount, customer information, funder information, repayment details, and installment information. The validity of null values ​​or missing data is verified. Simultaneously, the validity of data formats is validated, such as whether the amount and date formats conform to preset specifications. Abnormal characters are removed, and data encoding is standardized. If the validation passes, a financial context object is constructed based on the initial business data. This financial context object integrates core business event data, preliminary processing identifiers, and basic configuration information.

[0039] If the initial business data integrity check fails, a pre-defined retry mechanism is triggered. This involves retrieving the failed financial event message from the message queue, re-performing the deserialization using the previously configured JSON serialization mechanism, and regenerating the initial business data. This retry process is executed asynchronously using a thread pool and does not affect the normal processing of other messages. It aims to eliminate verification failures caused by temporary factors such as network fluctuations or incomplete message transmission.

[0040] A second integrity check is performed on the preliminary business data regenerated after the retry, with the same check criteria as the first one. If the second check still fails, it indicates that the message itself has substantial problems such as missing data or incorrect format. The financial event message is automatically transferred to a preset dead-letter queue to prevent it from occupying normal message processing resources. At the same time, a detailed error log is recorded, including key information such as message identifier, business event type, specific failure items of the two checks, processing time, and original message data, providing a complete basis for subsequent manual investigation and problem repair.

[0041] Please see Figure 3Step 103, which routes the financial context object to the corresponding scenario converter based on the business event type, may specifically include, but is not limited to, the following: 301. Based on the pre-configured mapping relationship between business event types and scene converter identifiers, perform a query according to the business event type to obtain the target scene converter identifier; 302. Obtain the corresponding scene converter based on the target scene converter identifier; 303. Route the financial context object to the corresponding scene converter.

[0042] In this embodiment, a pre-configured mapping table represents the mapping relationship between business event types and scene converter identifiers. This mapping table supports dynamic updates to adapt to new business scenarios. After obtaining the business event types from the initial business data, a preset query algorithm is used to retrieve the pre-configured mapping table and accurately match the unique scene converter identifier corresponding to that business event type. All scene converters follow a unified scene conversion interface specification and are uniformly managed by a scene converter factory class. The scene converter factory class maintains an association cache of scene converter identifiers and converter instances. After the target scene converter identifier is passed to the factory class, the factory class first retrieves the corresponding scene converter instance from the cache. If the cache is hit, it is returned directly; if the cache is not hit, the factory class dynamically creates a scene converter instance according to the instantiation rules corresponding to the identifier and stores it in the cache. At the same time, it verifies the availability of the instance to ensure that the returned scene converter can execute subsequent processing logic normally.

[0043] After obtaining the target scenario converter, the financial context object is used as the data carrier and passed to the scenario converter through an interface call. During the routing process, the integrity of the financial context object is maintained to ensure that core business data, preliminary processing identifiers, and other information are not lost or tampered with. At the same time, the routing component records key logs for this routing operation and adapts to asynchronous processing mechanisms to avoid blocking the parallel processing of other messages, ensuring that the routing operation is efficient and does not affect the overall system throughput.

[0044] Please see Figure 4 Step 104, which routes the enhanced context object to the corresponding adapter based on the characteristics of the business data fields, may specifically include, but is not limited to, the following: 401. Extract at least one dimension of features from the business data field features, including event type, funding source, payment channel and / or repayment details structure; 402. Based on a pre-built decision tree model, perform multi-level conditional judgments based on features of at least one dimension to obtain the judgment result; 403. Generate a business scenario code based on the judgment result; 404. Based on the business scenario code, query the mapping relationship between the pre-configured scenario code and the adapter identifier to obtain the target adapter identifier; 405. Obtain the corresponding adapter based on the target adapter identifier using the adapter factory class; 406. Route the enhanced context object to the corresponding adapter.

[0045] In this embodiment, target dimension information is extracted from the business data field features of the enhanced context object. The extraction process requires selecting at least one dimension based on the business scenario requirements. Specifically, the core business type identifiers such as loan disbursement, repayment, and compensation are extracted in the event type dimension; the fund provider attributes are extracted in the funding source dimension; the transaction execution channel is extracted in the payment channel dimension; and features such as the repayment amount composition and period distribution are extracted in the repayment details structure dimension. After feature extraction, the features are standardized, data formats and encoding rules are unified, outliers are removed, and the consistency and judgeability of each dimension feature are ensured. The pre-built decision tree model adopts a three-level classification logic design. The first-level judgment uses event type features as the core condition to initially divide the business into three core scenario branches: loan disbursement, repayment, and compensation. The second-level judgment further subdivides based on business data features. For example, in the repayment scenario, the scenario is subdivided into "full / partial repayment" and "normal / early repayment". The third-level judgment combines context features such as funding source and payment channel to complete the final scenario definition, such as normal repayment through online channels and first-time loan disbursement by a cooperating funder. During the judgment process, the decision tree model automatically matches features of each dimension with preset condition nodes, and progressively filters them in the order of first level, then second level, and finally third level, and finally outputs a unique scenario definition result. Moreover, the decision tree model supports dynamic updating of condition rules through the configuration center to adapt to business changes.

[0046] Based on the judgment results of the decision tree model, a corresponding business scenario code is generated. The business scenario code adopts standardized coding rules, and each business scenario code uniquely corresponds to a specific business scenario. After generation, a consistency check is performed to verify whether the business scenario code matches the extracted multi-dimensional features and judgment results, avoiding errors in the business scenario code due to feature extraction deviations or abnormal judgment logic. If the check passes, the final business scenario code is determined; if the check fails, an exception is marked and a retry mechanism is triggered.

[0047] Pre-configure mapping relationship table ( Figure 4 The mapping table of the embodiment and Figure 3(The mapping tables in the embodiments are not identical.) This mapping table indicates the mapping relationship between business scenario codes and adapter identifiers, and it also supports dynamic updates, allowing adaptation to new business scenarios without restarting. After obtaining the business scenario code, the mapping table is retrieved using an efficient query algorithm, and the corresponding adapter identifier is accurately matched according to the scenario code, ensuring the uniqueness and accuracy of the mapping.

[0048] The adapter factory class manages all adapter instances uniformly, and all adapters adhere to a unified adapter interface specification. Internally, the adapter factory class maintains a cache of the association between adapter identifiers and instances. Upon receiving a target adapter identifier, it first retrieves the corresponding instance from the cache. If the cache hits, it directly returns an available instance; otherwise, it dynamically creates an adapter instance according to the instantiation rules corresponding to the identifier. After creation, it verifies the instance's interface compatibility and functional availability, and stores it in the cache for later reuse, ensuring efficient acquisition of adapters.

[0049] After obtaining the target adapter, similar to step 303, the enhanced context object is completely passed to the adapter through standardized interface calls. During the routing process, it is ensured that information such as business module identifiers, multi-dimensional features, and core business data within the object are not lost or tampered with. At the same time, the routing component records key logs for this routing and adapts to the system's asynchronous processing mechanism to avoid blocking the parallel processing of other business events.

[0050] Please see Figure 5 Step 105, which involves calling the corresponding external system interface based on the accounting entry document, may include, but is not limited to, the following: 501. Based on the type of accounting entry document, obtain the corresponding instruction processor through the instruction dispatch factory class; 502. Using the instruction processor, generate a request to call the corresponding external system interface based on the accounting entry document; 503. Respond to requests according to the pre-set retry policy until the corresponding external system interface is successfully invoked.

[0051] In this embodiment, the instruction dispatch factory class uniformly manages the instruction processors of all external systems, and all instruction processors follow a unified instruction processing interface specification. First, the one-to-one correspondence between the types of accounting entries and external systems is clarified. After receiving the accounting entry, the instruction processor is located based on the type identifier and the one-to-one correspondence of the accounting entry. The retrieval process is similar to... Figure 3 or Figure 4 The embodiments shown are similar and will not be described again here.

[0052] After receiving the accounting entry document, the corresponding instruction processor first parses the core business data in the document, including key information such as accounting subject, debit / credit amount, business transaction number, processing time, and business scenario identifier. Then, it loads the corresponding external system's interface specification configuration and converts the parsed document data into request parameters recognizable by the external system according to this specification, completing parameter format adaptation, data verification, and signature encryption. Simultaneously, the request carries a unique business transaction number for traceability, associating it with the core context information of the accounting entry document to ensure consistency between the request and the original business event, ultimately generating a standardized call request that conforms to the external system's interface requirements.

[0053] The pre-configured retry strategy includes setting the maximum number of retries and the retry interval, defining retryable scenarios, and excluding unrecoverable errors. After the instruction processor sends a request, it monitors the response status of the external system in real time. If the call fails and falls within a retryable scenario, a retry is triggered according to the pre-configured strategy, and an error log is recorded before each retry. If the external system interface is successfully called during the retry process, the retry is terminated and the call result is returned. If the maximum number of retries is reached and the call still fails, a pre-configured compensation mechanism is triggered, such as manual intervention notification or transaction rollback triggering. At the same time, fault information is continuously recorded to ensure that the request is always responded to and does not block other business processes in the system.

[0054] The above embodiments illustrate the method for processing business events provided in this application. The following describes the business system, the apparatus for processing business events, and the storage medium provided in this application: Please see Figure 6 This application provides an embodiment of a business system, including: Asynchronous consumption unit 601 is used to asynchronously consume financial event messages in a preset message queue; The preprocessing unit 602 is used to preprocess financial event messages to obtain processing results, which include business event types and financial context objects. The first routing unit 603 is used to route the financial context object to the corresponding scenario converter according to the business event type, so that the scenario converter can process the financial context object and obtain an enhanced context object, which contains a business module identifier and business data field characteristics. The second routing unit 604 is used to route the enhanced context object to the corresponding adapter converter according to the characteristics of the business data fields, so that the adapter converter can process the enhanced context object and obtain the financial registration request instruction. Response unit 605 is used to respond to financial registration request instructions and generate accounting entry documents; Calling unit 606 is used to call the corresponding external system interface based on the accounting entry document so that the external system can respond to the financial event message.

[0055] Optionally, the preprocessing unit 602 is specifically used for: The financial event messages are deserialized to obtain preliminary business data, which includes the business event type. Perform integrity verification on the initial business data. If the integrity verification passes, construct a financial context object based on the initial business data.

[0056] Optionally, the preprocessing unit 602 is specifically used for: If the integrity check fails, repeat the steps of asynchronously consuming financial event messages in the preset message queue and deserializing the financial event messages; A second integrity check is performed. If the second integrity check fails, the corresponding financial event message is transferred to the dead letter queue and an error log is recorded.

[0057] Optionally, the first routing unit 603 is specifically used for: Based on the pre-configured mapping relationship between business event types and scenario converter identifiers, a query is executed according to the business event type to obtain the target scenario converter identifier; Obtain the corresponding scene converter based on the target scene converter identifier; The financial context object is routed to the corresponding scene converter.

[0058] Optionally, the second routing unit 604 is specifically used for: Based on the characteristics of business data fields, the corresponding business scenario code is obtained through a decision tree algorithm; Based on the business scenario code, query the mapping relationship between the pre-configured scenario code and the adapter identifier to obtain the target adapter identifier; The corresponding adapter is obtained by using the adapter factory class based on the target adapter identifier; The enhanced context object is routed to the corresponding adapter.

[0059] Optionally, the second routing unit 604 is specifically used for: Extract at least one dimension of features from the business data field features, including event type, funding source, payment channel and / or repayment details structure; Based on a pre-built decision tree model, multi-level condition judgments are made according to features in at least one dimension to obtain the judgment result; A business scenario code is generated based on the judgment result.

[0060] Optionally, calling unit 606 is specifically used for: Based on the type of accounting entry document, obtain the corresponding instruction processor through the instruction dispatch factory class; The instruction processor generates requests to call the corresponding external system interfaces based on accounting entries. The system responds to requests according to a pre-set retry policy until the corresponding external system interface is successfully invoked.

[0061] Please see Figure 7 This application provides an apparatus for processing business events, comprising: Processor 701, memory 702, input / output unit 703, and bus 704.

[0062] The processor 701 is connected to the memory 702, the input / output unit 703, and the bus 704.

[0063] The memory 702 stores a program, and the processor 701 calls the program to execute it, such as... Figure 1 , Figure 2 , Figure 3 , Figure 4 or Figure 5 The methods for handling business events in [the context of the application].

[0064] This application provides a computer-readable storage medium on which a program is stored, and when the program is executed on a computer, it performs the following... Figure 1 , Figure 2 , Figure 3 , Figure 4 or Figure 5 The methods for handling business events in [the context of the application].

[0065] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0066] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0067] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0068] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0069] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for processing business events, characterized in that, Applied to business systems, including: Asynchronous consumption of financial event messages in a pre-defined message queue; The financial event message is preprocessed to obtain a processing result, which includes the business event type and the financial context object. Based on the business event type, the financial context object is routed to the corresponding scenario converter, so that the scenario converter can process the financial context object to obtain an enhanced context object, which includes a business module identifier and business data field characteristics. Based on the characteristics of the business data fields, the enhanced context object is routed to the corresponding adapter, so that the adapter can process the enhanced context object and obtain the financial registration request instruction. In response to the financial registration request instruction, generate accounting entries; Based on the accounting entry document, the corresponding external system interface is invoked so that the external system can respond to the financial event message.

2. The method according to claim 1, characterized in that, The preprocessing of the financial event message to obtain the processing result includes: The financial event message is deserialized to obtain preliminary business data, which includes the business event type. The initial business data is subjected to integrity verification. If the integrity verification passes, a financial context object is constructed based on the initial business data.

3. The method according to claim 2, characterized in that, After performing integrity verification on the preliminary business data, the method further includes: If the integrity check fails, the steps of asynchronously consuming the financial event messages in the preset message queue and deserializing the financial event messages are executed again. A second integrity check is performed. If the second integrity check fails, the corresponding financial event message is transferred to the dead letter queue and an error log is recorded.

4. The method according to claim 1, characterized in that, The step of routing the financial context object to the corresponding scenario converter according to the business event type includes: Based on the pre-configured mapping relationship between business event types and scene converter identifiers, a query is performed according to the business event type to obtain the target scene converter identifier; Obtain the corresponding scene converter based on the target scene converter identifier; The financial context object is routed to the corresponding scene converter.

5. The method according to claim 1, characterized in that, The step of routing the enhanced context object to the corresponding adapter based on the characteristics of the business data fields includes: Based on the characteristics of the business data fields, the corresponding business scenario code is obtained through a decision tree algorithm; Based on the business scenario code, query the mapping relationship between the pre-configured scenario code and the adapter identifier to obtain the target adapter identifier; The corresponding adapter is obtained by using the adapter factory class based on the target adapter identifier; The enhanced context object is routed to the corresponding adapter.

6. The method according to claim 5, characterized in that, The step of obtaining the corresponding business scenario code using a decision tree algorithm based on the characteristics of the business data fields includes: Extract at least one dimension of features from the business data field features, the dimension including event type, funding source, payment channel and / or repayment details structure; Based on a pre-built decision tree model, multi-level condition judgments are performed according to the features of at least one dimension to obtain the judgment result; A business scenario code is generated based on the judgment result.

7. The method according to claim 1, characterized in that, The step of calling the corresponding external system interface based on the accounting entry document includes: Based on the type of the accounting entry document, the corresponding instruction processor is obtained through the instruction dispatch factory class; The instruction processor generates a request to call the corresponding external system interface based on the accounting entry document. The system responds to the request according to a pre-set retry policy until the corresponding external system interface is successfully invoked.

8. A business system, characterized in that, include: Asynchronous consumption unit, used for asynchronously consuming financial event messages in a preset message queue; The preprocessing unit is used to preprocess the financial event messages to obtain processing results, which include business event types and financial context objects. The first routing unit is configured to route the financial context object to the corresponding scenario converter according to the business event type, so that the scenario converter can process the financial context object to obtain an enhanced context object, wherein the enhanced context object contains a business module identifier and business data field characteristics; The second routing unit is used to route the enhanced context object to the corresponding adapter converter according to the characteristics of the business data field, so that the adapter converter can process the enhanced context object and obtain the financial registration request instruction. A response unit is used to respond to the financial registration request instruction and generate accounting entry documents; The calling unit is used to call the corresponding external system interface based on the accounting entry document, so that the external system can respond to the financial event message.

9. An apparatus for processing business events, characterized in that, include: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the method for processing business events as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, performs the method for processing business events as described in any one of claims 1 to 7.

Images