Transaction data interfacing method, visual generation apparatus, and enterprise data management system

Abstract

Disclosed are a transaction data interfacing method, a visual generation device and an enterprise data management system. The method comprises: selecting internal and external interfaces according to a target scenario of a transaction; setting the internal interfaces to correspond to start nodes and end nodes, and setting the external interfaces to correspond to intermediate nodes; connecting the nodes to construct a target scenario DAG; when the target scenario is a payment scenario of the transaction, constructing a sub-DAG for the intermediate nodes, which is used to asynchronously execute and return operation results of operations related to the intermediate nodes. When executed, a target scenario request is sent in as a parameter, whereby the DAG is executed to obtain an output result based on external operations as a request feedback. The present application simplifies the access of a system to external services and the acquisition of data by setting internal and external interfaces involved in each scenario in a transaction as nodes and thereby visually constructing a DAG, and provides a guarantee for payment data consistency by introducing a sub-DAG for asynchronous execution to obtain processing or compensation results that are not obtained when a main DAG is synchronously operated.

Description

Technical Field

[0001] This disclosure relates to the field of information technology processing, and more particularly to a data interface method, a visualization generation device, and an enterprise data management system. Background Technology

[0002] In many application scenarios, internal systems need to interface with external service providers to access various services offered by these providers and facilitate transactions between internal users and external service providers. For example, instead of employees booking rooms on their own through online booking websites, if the company's internal management system can connect to external booking websites and complete payments, employees can directly perform related operations on the company's internal travel service interface, greatly improving the company's efficiency in handling travel and subsequent financial matters.

[0003] In existing technologies, accessing external services typically requires programming one by one or is based on simple scripts, which is inefficient and cannot achieve service orchestration. At the same time, it is difficult to guarantee the consistency of payment data between internal and external systems.

[0004] Therefore, an improved transaction data integration solution is needed. Summary of the Invention

[0005] This disclosure addresses a technical problem by providing a transaction data integration method, a visualization generation device, and an enterprise data management system. The invention simplifies system access to external services and data acquisition by setting up internal and external interfaces involved in the transaction scenario as nodes and visually constructing corresponding DAGs (Directed Acyclic Graphs). For payment scenarios involved in transactions, a master-sub-DAG model allows asynchronously executed sub-DAGs to obtain processing or compensation results not acquired during synchronous operations of the master DAG through polling or notification, ensuring the consistency of payment data. Furthermore, the serial and parallel orchestration of intermediate nodes can integrate multiple external services to provide more efficient and comprehensive service functions.

[0006] According to a first aspect of this disclosure, a transaction data integration method is provided, comprising: selecting an internal interface and an external interface according to the target scenario of the transaction; setting the internal interface to correspond to a start node and an end node, and setting the external interface to correspond to an intermediate node; connecting the start node, the intermediate node, and the end node to construct a target scenario DAG; and when the target scenario is a payment scenario of the transaction, constructing intermediate nodes for the payment scenario DAG, wherein the sub-DAG is used to asynchronously execute and return the operation results of the intermediate node related operations, wherein a target scenario request is sent as an input parameter to the target scenario DAG, and the target scenario DAG is executed to obtain the output results based on the external operation as the request feedback.

[0007] The target scenario DAG is typically used for synchronous execution, but the operations of intermediate nodes in a payment scenario may include asynchronous execution operations triggered under specific circumstances. Therefore, optionally, constructing an asynchronous execution sub-DAG for the intermediate nodes of the payment scenario DAG includes: adding a related message line from the intermediate node to the start node of the asynchronous execution sub-DAG, and adding a related message line from the end node of the asynchronous execution sub-DAG to the intermediate node, to construct an asynchronous execution polling sub-DAG executed based on polling of the intermediate node. Alternatively, constructing an asynchronous execution sub-DAG for the intermediate nodes of the payment scenario DAG may include: setting a mechanism for triggering the start node operation of the asynchronous execution sub-DAG upon completion of operations related to the intermediate node, and adding a related message line from the end node of the asynchronous execution sub-DAG to the intermediate node, to construct an asynchronous execution message sub-DAG executed based on the completion of operations related to the intermediate node, wherein the related message line is used to connect the start-point message to the triggering of the end-point operation.

[0008] Optionally, the method further includes: constructing a notification sub-DAG for the end node, for assembling the operation result returned by the asynchronous execution sub-DAG based on the operation result, and returning the operation result to the internal interface based on the message template in an execution notification.

[0009] Optionally, connecting the start node, the intermediate node, and the end node to construct the target scene DAG includes: setting a call input parameter template and a call protocol for the intermediate node, and setting a notification template for the end node, wherein parameters from the preceding node are placed in the input parameter template to obtain the call input parameters of the current intermediate node, the call protocol is used to implement the call to the external interface corresponding to the current intermediate node, and the end node generates the output result based on the notification template according to the input parameters from the preceding intermediate node.

[0010] Optionally, selecting internal and external interfaces according to the target scenario includes: determining multiple functional steps to be executed according to the target scenario; selecting various required external interfaces for each functional step, and connecting the start node, the intermediate node and the end node to construct the target scenario DAG includes: setting multiple external interfaces as serial intermediate nodes corresponding to the target scenario DAG, and connecting each serial intermediate node one by one according to the functional steps.

[0011] Optionally, selecting internal and external interfaces according to the target scenario includes: selecting multiple external interfaces from different service providers that can implement the same scenario function, and connecting the start node, the intermediate node and the end node to construct the target scenario DAG includes: setting the multiple external interfaces as parallel intermediate nodes corresponding to the target scenario DAG, and connecting each of them to upstream and downstream nodes.

[0012] According to a second aspect of this disclosure, a data docking DAG visualization generation apparatus is provided for performing the method as described in the first aspect in a graphical user interface to construct a visualized target scene DAG.

[0013] According to a third aspect of this disclosure, an enterprise data management system is provided, comprising: a DAG construction module, configured to create multiple target scenarios involved in transactions with external entities, and execute the transaction data docking method as described in the first aspect for each target scenario to construct a corresponding target scenario DAG; and a DAG execution module, configured to execute the corresponding target scenario DAG upon receiving a target scenario request from an internal user, so as to return the request result to the user.

[0014] Optionally, the DAG execution module is configured to: receive a request from a user for the target scenario through the internal interface; send the target scenario request as an input parameter into the target scenario DAG; execute the target scenario DAG and obtain the execution result based on the external service to generate a request result; and return the request result to the user.

[0015] Optionally, executing the corresponding target scene DAG includes: traversing the target scene DAG to determine nodes with an in-degree of 0 and obtaining context parameters and node configuration; performing operations corresponding to each node with an in-degree of 0 in parallel based on the obtained context parameters and node configuration; putting the node execution results into the context and decrementing the in-degree of adjacent edges on the node by 1; and repeating the above operations until the operation of the entire target scene DAG is completed.

[0016] Optionally, the parallel execution of the operation corresponding to each node with an in-degree of 0 based on the obtained context parameters and node configuration includes: when the node configuration includes an associated message line, generating the driving input parameters of the sub-DAG according to the associated message configuration and driving the asynchronous execution of the sub-DAG; and obtaining the asynchronous execution result of the sub-DAG for the generation of the request result.

[0017] According to a fourth aspect of this disclosure, a computing device is provided, comprising: a processor; and a memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method described in the first aspect above.

[0018] According to a fifth aspect of this disclosure, a non-transitory machine-readable storage medium is provided, on which executable code is stored, which, when executed by a processor of an electronic device, causes the processor to perform the method described in the first aspect above.

[0019] Therefore, this invention improves the convenience and efficiency of external service access to complete transactions by using the visualization mode and node settings of DAG; it solves the timeout and order drop problem in transaction payment scenarios by configuring master and child DAGs, and is suitable for the financial field with high requirements for data consistency; it supports multi-node service orchestration, so that subsequent nodes can obtain the execution data of previous nodes, and can orchestrate the various interfaces of external service providers into new interfaces and output service capabilities. Attached Figure Description

[0020] The above and other objects, features and advantages of this disclosure will become more apparent from the more detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings, wherein like reference numerals generally denote like parts.

[0021] Figure 1 A schematic flowchart of a transaction data docking method according to an embodiment of the present invention is shown.

[0022] Figure 2 An example of a directed acyclic graph is shown.

[0023] Figure 3 An example of a target scene DAG constructed according to the present invention is shown.

[0024] Figure 4A -B illustrates an example of a master DAG constructed according to the present invention.

[0025] Figure 5A -B illustrates an example of node configuration according to the present invention.

[0026] Figure 6 An example of a target scenario DAG constructed according to the present invention, capable of service orchestration, is shown.

[0027] Figure 7 A schematic diagram of the composition of an enterprise data management system according to an embodiment of the present invention is shown.

[0028] Figure 8 A schematic diagram of a computing device that can be used to implement the above-described data interface method according to an embodiment of the present invention is shown.

[0029] Figure 9 An example of the algorithm implementation for the master-slave DAG connector is shown. Detailed Implementation

[0030] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0031] In many application scenarios, internal systems need to interface with external service providers to complete various transactions. For example, by connecting to external hotel booking websites, an enterprise's internal management system can enable employees to directly complete hotel room browsing, booking, and payment transactions through the enterprise's internal travel service interface, thereby improving the efficiency of the enterprise in handling travel and subsequent financial matters.

[0032] In existing technologies, accessing external services typically requires programming each service individually, or using a single external interface as a gateway and employing scripts to handle parameter mapping. These methods are inefficient, fail to orchestrate services for efficient task execution, and struggle to guarantee data consistency between internal and external systems.

[0033] To address this, the present invention provides a transaction data integration method and an enterprise data management system for implementing this method. The present invention simplifies the system's access to external services by setting up internal and external interfaces involved in various target scenarios of transactions as nodes and visually constructing the corresponding DAGs (Directed Acyclic Graphs). Through a master-child DAG model, asynchronously executed child DAGs can obtain processing or compensation results not acquired during synchronous operations of the master DAG through polling or notification, thereby ensuring data consistency. Furthermore, multiple external services can be integrated through the serial and parallel orchestration of intermediate nodes to provide more efficient service functions.

[0034] Figure 1 A schematic flowchart illustrating a transaction data interoperability method according to an embodiment of the present invention is shown. The main aspect of this method is the construction of a Directed Acyclic Graph (DAG) for interoperating transaction data between internal and external systems. After constructing DAGs corresponding to various target scenarios involved in the transaction, the appropriate DAG can be selected and executed when needed.

[0035] In step S110, internal and external interfaces are selected based on the target scenario of the transaction. Here, the internal interface is the interface between the system and the outside world, while the external interface is the interface provided by the service provider outside the system.

[0036] In this invention, a transaction is the act of a user within an internal system using currency to interact with services or goods provided by an external service provider. For example, a user of an enterprise management system can complete hotel reservations and payments, hail a ride, and pay for similar services on a page within the enterprise's internal system. Transactions often involve multiple scenarios. For instance, in a hotel transaction, a user needs to browse hotels, select a preferred hotel, and then make a payment. In a travel transaction, a user needs to confirm the vehicle they will be using and also make a payment. Regardless of the type of transaction, a payment scenario is involved.

[0037] Enterprise data management systems access external services in various scenarios involved in transactions. For example, when booking a hotel, the system's information retrieval interface can access hotel browsing services from external booking websites; when making a payment, the system's standard payment interface can access payment services from external payment service providers. Therefore, it is necessary to select the relevant internal and external interfaces for each specific transaction scenario and construct the corresponding transaction scenario DAG accordingly.

[0038] In embodiments of the present invention, the system can be configured to still be aware of every operation performed by the user (e.g., an internal user) when interacting with these external services. In other words, the system can enable the user to complete every operation, such as booking a hotel or making a payment, within the internal management system interface (i.e., every interaction between the user and the external service is completed through the internal system). For example, when an internal user needs to book a hotel for business travel, the system does not directly redirect to an external booking website from the internal system. Instead, the user submits a booking request on the business travel page of the internal management system. The internal system then interacts with the external booking website to display a list of available hotels on the internal page. After the user selects the hotel and room type on the internal page, the internal system notifies the external booking website of the selection result. Similarly, when paying for the room, the user performs the operation on the internal page, and the internal system connects with an external payment service provider to complete the payment. Here, displaying a hotel list to the internal user based on the booking request, informing them of the selected hotel and room type, and finally paying the room fee can each correspond to a specific transaction scenario, and thus each corresponds to a scenario DAG.

[0039] Therefore, to ensure that all user operations are completed within the system, the overall transaction service provided by the external service provider is divided into several scenarios. These scenarios correspond to microservices, and for each microservice, the relevant internal and external interfaces are selected to construct a scenario DAG.

[0040] To this end, the system's internal requirements for connecting to external services can be broken down into individual scenarios, and in step S110, the selection of internal and external interfaces to be used in the current scenario (i.e., the "target" scenario currently being set) can be completed. For example, in a payment scenario that requires payment, the system's standard payment interface can be selected as the internal interface, and the payment interface of the external payment service provider can be selected as the external interface.

[0041] After selecting the interface, the node type corresponding to the interface in the DAG can be set. Therefore, in step S120, the internal interface is set to correspond to the start and end nodes, and the external interface is set to correspond to the intermediate nodes. In step S130, the start node, the intermediate node, and the end node are connected to construct the target scene DAG. During actual execution, the target scene request is sent as an input parameter to the target scene DAG, and the target scene DAG is executed to obtain the output result based on the external operation as the request feedback.

[0042] A Directed Acyclic Graph (DAG) is a type of directed graph that can be used to represent driving dependencies between events. Therefore, in this invention, it is used to manage the scheduling of tasks and the transfer of data between interfaces (in the form of input parameters and output parameters of nodes).

[0043] Figure 2 An example of a directed acyclic graph (DAG) is shown. The graph illustrates a relatively complex DAG where the seven "nodes" (also called "vertices") x1-x7 represent seven tasks with dependencies. The directed vectors (i.e., "edges") connecting two nodes represent the dependencies between tasks. The sum of the number of times each node is the endpoint of an edge in the graph is the in-degree of that node. Figure 2 In the example, x1, x2, x3, and x7 have an in-degree of 0, meaning there are no edges that terminate at them. This implies that the execution of x1, x2, x3, and x7 does not depend on other nodes in the graph, so these four nodes with an in-degree of 0 can be considered the starting nodes of the DAG. x5, x6, and x8 in the graph have no edges that begin at them, so these three nodes can be considered the ending nodes of the DAG. x4, however, has edges that both begin and end at it, making it an intermediate node.

[0044] In this invention, since the internal system needs to obtain external services, each target scenario can be viewed as an internal interface providing an internal request to an external service provider, and then obtaining the service result provided by the external service provider to the internal request through the internal interface. Therefore, the start node and end node need to correspond to the internal interface to facilitate the internal system sending out the request and obtaining the service result data of the external service. The intermediate node corresponds to the external interface; that is, the external service provider obtains the task to be executed and the input parameters through the external interface from the start node to the intermediate node (i.e., the data transmission path, where "data" can include instruction data, parameter data, or both), executes the corresponding service, and sends the service result through the edge from the intermediate node to the end node, thus enabling the internal system to obtain the external service result data.

[0045] Figure 3 An example of a target scenario DAG constructed according to the present invention is shown. As shown in the figure, this DAG corresponds to a refund scenario and includes a start node, an intermediate node ("refund" node), and an end node. Each node can include a corresponding unique node ID. The start node and end node can correspond to the system's standard refund interface; that is, the start node and end node correspond to the same internal interface, while the intermediate node corresponds to an external interface provided by an external service provider, thereby completing the "refund" operation. When a refund needs to be completed through a service provided by an external payment service provider, the system's standard refund interface can obtain, for example, a refund request from an internal user and transmit the refund request to the external refund service interface corresponding to the intermediate node via an edge from the start node to the intermediate node. After the external service provider completes the refund service, it transmits the result to the standard refund interface via an edge from the intermediate node to the end node, thereby completing the external refund.

[0046] As shown in the example above, in some embodiments, the start and end nodes of a DAG can correspond to the same internal interface, thereby enabling the same interface to send requests and receive results. However, in other embodiments, the start and end nodes of a DAG can correspond to different internal interfaces, and this invention does not impose any limitations on this. Furthermore, it should be understood that although the start and end nodes of the same DAG can correspond to the same interface, since the aforementioned interface is used to complete different tasks at different times, it can still be set to correspond to two nodes separated by an intermediate node in the directed acyclic graph.

[0047] The Directed Acyclic Graphs (DAGs) involved in various scenarios within a transaction are typically used for the synchronous execution of requests and the receipt of feedback. For example, when a user enters a hotel booking request for city A in the hotel booking module of an internal system, the following can be executed immediately: Figure 6The "Hotel Static Information" DAG shown retrieves and displays a list of basic hotel information within the internal system. Users can then browse and select the desired hotel on the internal system page and send a booking request. This triggers subsequent DAGs such as "Hotel Booking" and "Payment" to complete the booking. The "Hotel Booking" and "Payment" DAGs are typically executed immediately upon receiving the user's request and return the execution result.

[0048] However, in certain situations, especially those involving monetary exchanges such as payments from internal users to external service providers or refunds from external service providers to internal users, strong guarantees for data consistency are required. However, in such financial scenarios, situations frequently arise where external payment service providers fail to respond within a specified timeframe. Existing technologies require additional reconciliation measures to recover from order drops afterward. Since post-event verification typically occurs several days later, it significantly impacts the user experience. This invention addresses this by introducing a sub-DAG that can be executed asynchronously to achieve order drop recovery operations that guarantee data consistency. When including the sub-DAG, the DAG used in the target scenario can be considered the main DAG.

[0049] As mentioned earlier, to ultimately complete a transaction, a payment scenario is inevitably included among the multiple scenarios involved in an transaction. In the payment scenario, since monetary expenditures (in the form of transfers) are involved, data consistency between internal and external systems needs to be ensured. Therefore, the data integration method of this invention further includes step S140, which involves constructing a sub-DAG for asynchronous execution. In step S140, when the target scenario is the payment scenario of the transaction, an intermediate node for the payment scenario DAG is constructed. This sub-DAG is used to asynchronously execute and return the operation results of the relevant operations of the intermediate node.

[0050] The target scenario DAG is used for synchronous execution, and when the operations of intermediate nodes in the payment scenario include asynchronous execution operations triggered by specific situations, it is necessary to construct an asynchronously executed sub-DAG for the intermediate nodes. In this invention, the payment scenarios that require constructing asynchronously executed sub-DAGs for intermediate nodes involve various scenarios where there are transfer behaviors between internal system users and external service providers, including actual payment scenarios from users to external service providers, frozen transfer scenarios, and scenarios where external service providers refund payments to users, i.e., refund scenarios.

[0051] Sub-DAGs constructed for intermediate nodes can be divided into polling sub-DAGs and message sub-DAGs. Polling sub-DAGs are triggered by the intermediate nodes of their connected main DAGs, for example, via associated message lines that trigger operations on the connection from the starting point to the ending point, and this process continues until the sub-DAG returns the desired result. Message sub-DAGs, on the other hand, are typically not triggered in real-time by the intermediate nodes of their connected main DAGs, but rather when a predetermined condition is met. Therefore, message sub-DAGs only include associated message lines that trigger operations on the intermediate nodes of the sub-DAG's ending node. Associated message lines can be used to trigger operations on the connection from the starting point to the ending point. Furthermore, associated message lines can also implement data mapping, that is, converting the parameters of one DAG node (usually an intermediate node of the main DAG that hosts the sub-DAG) into triggering parameters for another DAG node (usually the starting node of the sub-DAG).

[0052] Therefore, constructing an asynchronous execution sub-DAG for intermediate nodes in a payment scenario can include: adding a related message line from the intermediate node to the start node of the asynchronous execution sub-DAG, and adding a related message line from the end node of the asynchronous execution sub-DAG to the intermediate node, to construct an asynchronous execution polling sub-DAG executed based on polling of the intermediate node. Alternatively, constructing an asynchronous execution sub-DAG for intermediate nodes in a payment scenario can include: setting a mechanism that triggers the start node operation of the asynchronous execution sub-DAG upon completion of operations related to the intermediate node, and adding a related message line from the end node of the asynchronous execution sub-DAG to the intermediate node, to construct an asynchronous execution message sub-DAG executed based on the completion of operations related to the intermediate node.

[0053] Furthermore, a notification sub-DAG can be constructed for the end node, which is used to assemble the operation result returned by the asynchronous execution sub-DAG into an execution notification based on the message template and return it to the internal interface.

[0054] Figure 4A -B illustrates an example of a master DAG constructed according to the present invention. Both master DAGs relate to payment scenarios. Figure 4A A refund transaction scenario involving refunds, Figure 4B This involves a payment transaction scenario where funds are frozen and then transferred to another payment.

[0055] Specifically, Figure 4A This illustrates a service orchestration pattern of a main refund DAG and a polling refund sub-DAG. The internal system defines a standard refund interface for synchronously retrieving refund results from external service providers. This can be achieved through the following combination: Figure 5A-B describes the DAG and node setup, which uses the same standard refund interface to connect to multiple payment institutions (i.e., multiple external payment service providers), such as Institution A, Institution B, etc., whose interfaces differ from each other.

[0056] Because there are two scenarios where orders are dropped: either the main DAG times out when calling the payment institution, or the standard refund interface, which is an internal interface in the DAG, times out when calling the main DAG (in which case the actual refund at the payment institution is successful, but the internal interface fails to retrieve the refund), asynchronous execution of the sub-DAG is introduced to recover from dropped orders.

[0057] Specifically, while configuring a main refund DAG to obtain synchronous refund results, a receipt is configured for the refund node, which acts as an intermediate node. The refund result is obtained through the sub-DAG triggered by the refund polling task, thereby compensating for timeout and order loss. Figure 4A It can be seen as targeting Figure 3 The optimization involves adding an additional sub-DAG for asynchronous execution, taking into account the potential order drop issues during the refund process.

[0058] During configuration, the main refund DAG is first bound to the standard refund interface provided by the corresponding internal system. The start and end nodes are also bound to the corresponding refund interfaces. The intermediate refund nodes correspond to the refund interface of Institution A (since the internal system can find the corresponding Institution A based on payment records or the user can select Institution A when initiating a refund, this DAG can connect only to Institution A's refund interface, or select only Institution A's refund interface when connecting to multiple institutions' refund interfaces). Results are obtained synchronously. On the nodes, the main configuration includes input parameter assembly, assertion rules, error code mapping, and receipt templates, using a visual selection mode. The end node configures the output parameter assembly result for the refund. The execution of this main-sub-DAG ends with the refund message from the final sub-DAG.

[0059] The diagram includes two sub-DAGs: one is a "Refund Query Compensation" sub-DAG attached to the refund node for refund polling. This sub-DAG comes into play when the synchronization interface fails to retrieve data. It polls for refund queries from institution A ("XXX Payment" in the diagram), obtains the refund receipt, and updates the receipt in the main DAG's refund node's receipt section. The other sub-DAG, attached to the termination node, is mainly used to assemble the receipt into a notification format required by the internal system, sending the result, for example, to internal users requesting a refund. This solves the timeout problem caused by data integration in payment scenarios.

[0060] Figure 4BThis illustrates the service orchestration of the main payment DAG along with the sub-payment message DAG. Here, a standard internal payment interface is also required to connect to multiple payment institutions. For example, if the interface includes different institutions A and B, further calls are needed to ensure data consistency between the two parties involved in the data exchange.

[0061] To address this, a main DAG for freezing and transferring payments can be configured to complete the payment application and obtain the acceptance number. Since payment processing after freezing typically occurs intermittently, and polling mechanisms are too costly, the actual payment processing result can be obtained through a sub-DAG triggered by the receipt.

[0062] During configuration, the main DAG for frozen payment is first bound to the standard payment interface provided by the internal system. The start and end nodes are also bound to the corresponding payment interfaces. The payment nodes, acting as intermediate nodes, correspond to the refund payment interface of Institution A. On the nodes, the main configuration options, such as input parameter assembly, assertion rules, error code mapping, and receipt templates, are configured through a visual selection mode. The end node is configured with the output parameter assembly result of the business payment application.

[0063] Figure 4B The process also includes two sub-DAGs: one is a message sub-DAG triggered by the payment message of structure A attached to the intermediate node, which is mainly used to update the receipt of the main DAG node; the other is a sub-DAG attached to the end node, which is mainly used to assemble the receipt into the notification format required by the internal system and send the result to internal users, such as actual payment users, in a notification mode.

[0064] Therefore, this invention achieves asynchronous processing of synchronous requests through a master-sub-DAG. It should be understood that the message sub-DAG attached to intermediate nodes for reporting operation completion and the notification sub-DAG attached to the end node for generating internal system notifications can both be considered as the same type of sub-DAG used for information generation.

[0065] In practice, external service providers may exhibit various differences in messages, protocols, and interactions. In this invention, to enable, for example, a standard refund interface to seamlessly connect to various external refund interfaces, it is necessary to configure each node, especially the intermediate nodes involved in external operations. To this end, connecting the start node, the intermediate nodes, and the end node to construct a target scenario DAG may include: setting a call input parameter template and a call protocol for the intermediate nodes, and setting a notification template for the end node. Parameters from the preceding node are placed in the input parameter template to obtain the call input parameters of the current intermediate node. The call protocol is used to implement the call to the external interface corresponding to the current intermediate node. The end node generates the output result based on the input parameters from the preceding intermediate nodes according to the notification template.

[0066] In some embodiments, output parameters can be set for the start node, and input parameters can be set for the intermediate and end nodes. In other embodiments, only one end of the edge can be set. For example, no output parameters can be set for the start node (or the default settings can be used directly), and input parameters can be set for the intermediate nodes connected to the start node; no output parameters can be set for the intermediate nodes (or the default settings can be used directly), and input parameters can be set for the subsequent nodes connected to the intermediate nodes (e.g., another intermediate node or the end node), etc. Additionally, the end node can also generate the output result based on the notification template according to the input and output parameters of the preceding intermediate nodes in the example.

[0067] The input parameter template (or the output parameter template of the previous node) is designed to mitigate the impact of differences in message format (e.g., field naming and order) between internal and external interfaces on transmission. For example, Figure 3 The internal refund interface corresponding to the starting node shown receives refund requests from internal users. These requests contain various information such as transaction number and refund amount. This information can be provided by the internal refund interface to the external refund interface corresponding to the intermediate node. However, due to differences in message format, the external refund interface cannot directly extract useful information from the messages from the internal refund interface. In this case, the input parameter template can be configured to specify the field arrangement and processing of each field, thereby enabling the refund information to be fed to the external refund interface in a format that the external refund interface can understand. Figure 5A -B illustrates an example of node configuration according to the present invention. Figure 5A The configuration page for the payment / refund node is shown. As shown in the figure, you can assign transaction codes, determine message formats, and specify API paths. You can also configure the fields involved in the input and output parameters. Figure 5B The page displays detailed field settings. As shown in the figure, you can configure the amplitude source, value, and post-processing for each field involved in payment refunds.

[0068] Similarly, the protocol settings aim to eliminate protocol differences between different interfaces. When executing a corresponding node, the protocol used by the current interface can be invoked. Therefore, during the execution of an intermediate node, context parameters and the current node configuration can be obtained, the input parameter template for the node call can be retrieved, the actual obtained context parameters can be placed into the assembly template to obtain the actual call input parameters, the interface can be invoked according to the calling protocol of the node's bound interface, and the success of the interface call can be determined according to the node's configuration assertion rules. If successful, it can be handed over to an external service provider for appropriate processing, such as refund processing.

[0069] In a preferred embodiment of the invention, service orchestration can be achieved by configuring multiple intermediate nodes in a DAG. That is, more complex service functions can be implemented by arranging intermediate nodes corresponding to specific external interfaces. In this process, intermediate nodes can be configured sequentially, in parallel, or a combination of both.

[0070] Therefore, in one embodiment, selecting internal and external interfaces based on the target scenario may include: determining multiple functional steps to be executed based on the target scenario; and selecting various required external interfaces for each functional step. Connecting the start node, the intermediate nodes, and the end node to construct the target scenario DAG may include: setting the multiple external interfaces as serial intermediate nodes corresponding to the target scenario DAG, and connecting each serial intermediate node one by one according to the functional steps.

[0071] In another embodiment, selecting internal and external interfaces based on the target scenario may include: selecting multiple external interfaces from different service providers that can implement the same scenario functionality. Connecting the start node, the intermediate node, and the end node to construct the target scenario DAG may include: setting the multiple external interfaces as parallel intermediate nodes corresponding to the target scenario DAG, and connecting each to its upstream and downstream nodes.

[0072] Figure 6 An example of a transaction scenario DAG constructed according to the present invention, capable of service orchestration, is shown. In other embodiments, obtaining the access token (i.e., the Access Token in the diagram), obtaining the available hotel ID, and obtaining the hotel's basic information can also be divided into three different DAGs, but... Figure 6 By orchestrating services, the three nodes are serially set up in a DAG for obtaining "hotel static information", thereby enabling users to directly obtain basic information about hotels in the city they are looking for when they search for hotels within the system.

[0073] Furthermore, although Figure 6The example shows a "Get Hotel Basic Information" node, but this node can include multiple child nodes configured in parallel to connect to multiple external booking service providers. For example, child node A corresponds to external booking service provider 1, child node B corresponds to external booking service provider 2, child node A is connected between the "Get Available Hotel IDs by City ID" node and the end node, and child node B is similarly connected between the "Get Available Hotel IDs by City ID" node and the end node. During the actual execution of the DAG, the "Get Hotel Basic Information" node can select to execute each child node mode, thereby simultaneously obtaining hotel information provided by multiple external booking service providers. Furthermore, when the internal system needs to connect to more external booking service providers (e.g., external booking service provider C), this can be easily accomplished by adding another child node to the "Get Hotel Basic Information" node and configuring it accordingly.

[0074] Furthermore, it should be understood that when a DAG includes multiple intermediate nodes due to service orchestration, if the intermediate operations involve background operations of an internal system, then in addition to the intermediate nodes corresponding to the external interfaces providing external services, the DAG may also include intermediate nodes corresponding to internal interfaces or operations. In other words, the start and end nodes of the DAG need to correspond to internal interfaces, and at least one intermediate node needs to correspond to an external interface. Other intermediate nodes can also correspond to internal interfaces when needed; this invention does not impose any restrictions on this.

[0075] In this invention, multiple scenarios can be set up to complete a transaction, and a corresponding Directed Acyclic Graph (DAG) can be constructed for each scenario. Thus, in subsequent practical operations, the transactions between the internal system and the external service provider are jointly realized through multiple DAGs. In embodiments of this invention, it is preferable to set different DAGs for different situations. For example, in the same payment scenario, as shown below... Figure 5A As shown on the left, it includes multiple sub-functions such as pre-authorization freezing, fund authorization operation query, frozen payment, pre-authorization unfreezing, pre-authorization revocation, refund, payment query, and refund query. Each function can construct a DAG accordingly, or construct a main sub-DAG that includes asynchronous execution sub-DAGs.

[0076] The transaction data integration method of this invention can particularly realize a visual transaction data integration method, which can perform DAG construction and node setting in a graphical user interface, and can generate a visual target scene DAG. Thus, through visual orchestration and mapping, the efficiency of data integration is improved.

[0077] This invention can also be implemented as a visualization generation system for connecting transaction data to a DAG, enabling node selection and interface mapping, as well as node configuration (e.g., ...) within a graphical user interface. Figure 5AAs shown in the configuration page (as shown in -B), the visualization generates DAGs for various trading scenarios (e.g., Figure 3 , Figure 4A -B and Figure 6 The system shown above for generating data interface DAGs can also be called a connector generation system. That is, it treats each DAG connecting internal systems and external services as a connector, which together enable specific functions of the internal system based on external services, such as financial functions, travel functions, and access functions. The system used to generate these connectors can be implemented as a connector cloud platform, or PaaS. Enterprise users can use this cloud platform to complete the necessary DAGs for interaction between their internal systems and various external service providers, thus providing convenient and reliable services to internal users of the enterprise's internal systems.

[0078] This invention can be particularly implemented as an enterprise data management system. Figure 7 A schematic diagram of the composition of an enterprise data management system according to an embodiment of the present invention is shown. As shown, the system 700 may include a DAG construction module 710 and a DAG execution module 720.

[0079] DAG construction module 710 is used to create multiple target scenarios involved in transactions with external entities, and executes the data integration method described above for each target scenario to construct the corresponding target scenario DAG. DAG construction module 710 can be implemented through the connector cloud platform described above. When the enterprise data management system itself is also implemented on a cloud platform, the enterprise can obtain the DAG construction functionality provided on the cloud platform through additional purchase or other means.

[0080] The DAG execution module 720 is used to execute the corresponding target scenario DAG when a target scenario request is received from an internal user, so as to return the request result to the user. The DAG execution module 720 can be part of various service function modules of the enterprise data management system 700. For example, the enterprise data management system 700 includes a travel module, a transportation module, and a financial module, etc., used to provide corresponding travel, transportation, and financial services to internal employees. When the corresponding services of these modules need to interact with external services to be realized, it is necessary to execute the DAG under the corresponding transaction scenario. In this case, the travel module, transportation module, and financial module can all be regarded as modules that execute the DAG, i.e., module 720.

[0081] Specifically, the DAG execution module is used for: receiving a request from a user for the target scenario through the internal interface; sending the target scenario request as an input parameter into the target scenario DAG; executing the target scenario DAG and generating a request result based on the execution result of the external service; and returning the request result to the user.

[0082] Executing the corresponding target scene DAG may include: traversing the target scene DAG to determine the nodes with an in-degree of 0 and obtaining context parameters and node configuration; performing the corresponding operations for each node with an in-degree of 0 in parallel based on the obtained context parameters and node configuration; putting the node execution results into the context and decrementing the in-degree of the adjacent nodes on the node by 1; and repeating the above operations until the operation of the entire target scene DAG is completed.

[0083] The parallel execution of operations corresponding to each node with an in-degree of 0 based on the obtained context parameters and node configuration may include: when the node configuration includes associated message lines, generating the driving input parameters of the sub-DAG according to the associated message configuration and driving the asynchronous execution of the sub-DAG; and obtaining the asynchronous execution result of the sub-DAG for the generation of the request result.

[0084] Figure 8 A schematic diagram of a computing device that can be used to implement the above-described data interface method according to an embodiment of the present invention is shown.

[0085] See Figure 8 The computing device 800 includes a memory 810 and a processor 820.

[0086] Processor 820 may be a multi-core processor or may contain multiple processors. In some embodiments, processor 820 may include a general-purpose main processor and one or more special coprocessors, such as a graphics processing unit (GPU), a digital signal processor (DSP), etc. In some embodiments, processor 820 may be implemented using custom circuitry, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0087] Memory 810 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 820 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 810 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 810 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0088] The memory 810 stores executable code, which, when processed by the processor 820, enables the processor 820 to execute the data docking method described above.

[0089] Application examples

[0090] To further deepen the understanding of the principles of this invention, the following description will be based on the actual construction and implementation examples of DAG.

[0091] Figure 9This diagram illustrates an algorithmic implementation example of a master-child DAG connector. As shown in the figure, the DAG model (ExchangeDirectedGraph) can include a vertex set, dag code (dagCode), and transaction code (transcode). The vertex set includes multiple vertex models (ExchangeVertex), which contain information about adjacent edges (adjEdge), in-degree, node ID (nodeId), associated sub-DAGs, and associated message lines. A vertex model can correspond to multiple edge models, which include start and end vertex information. Each vertex model corresponds to a node detail model and multiple event models (EventModel). The node detail model includes node ID, data transfer object (DTO) template, and interface transaction code, while the event model specifies the relevant content of the associated message lines, such as associated message ID, triggering node ID, and acknowledgment node ID.

[0092] Each node's detailed model corresponds to a MethodDTO (Device-to-Transaction) model. This model is used for interface setup, including interface transaction code, calling protocol, input parameter template, result message template, and serial number.

[0093] The master-slave DAG connector implemented as described above can be operated as follows in actual execution.

[0094] Execution of the main DAG:

[0095] (1) Assemble the configured nodes and edges into a dag graph (directedGraph);

[0096] (2) Traverse the directedGraph to get the vertices with an in-degree of 0, and add them to postVertexes (the set of vertices with an in-degree of 0 to be executed);

[0097] (3) The logic of each node in postVertexes is executed in parallel using the future pattern. When traversing each node, context parameters are obtained, including internal interface input parameters, the context result of the previous node call (including the input parameters and result of the previous node), and node mapping configuration. The triggering logic of each node involves calling external or internal interfaces or sending messages, etc. In the asynchronous thread, each node's logic is executed, specifically:

[0098] a. Obtain context parameters (as in the previous step) and node configuration;

[0099] b. Obtain the input parameter template for the node call, put the actual obtained context parameters into the assembly template to obtain the actual call input parameters, and call the interface according to the calling protocol of the node bound interface.

[0100] c. Determine whether the interface call is successful based on the assertion rules configured in the node. For example, if the assertion rule is configured as [[{'assertKey':'${result.body.success}','assertValue':'true','op':'EQ'}]], it means that if the returned result is success=true, it is considered successful. The assertion rule engine supports "or" and "AND" rules.

[0101] If steps d and c fail, the error code of the organization is converted to the business error code. For example, the organizational error code 0001 is considered a system error, and the defined standard error code is SYSTEM_ERROR.

[0102] e. Determine if the node contains a receipt (used to asynchronously obtain the execution result of the node). If a receipt template is configured and there is an associated message line under the node, generate the driver input parameters of the sub-dag according to the mapping template configured on the associated message. This step of driving the sub-dag is executed asynchronously.

[0103] f. Record node execution records. The node status record for synchronization is FINISH. The acknowledgment status needs to be configured as PROCESS. At the same time, record the corresponding order number.

[0104] g. Put the node execution result into the context, decrement the in-degree of the adjacent nodes of the node by 1, and then increment the count (corresponding to the number of vertices traversed) by 1;

[0105] h. If the in-degree of a node's neighboring vertices is 0, add that vertex to postVertexes;

[0106] (4) Check if postVertexs is empty. If not, go to step 3.

[0107] (5) Determine whether the count of count is equal to the number of vertices in directedGraph. If they are not equal, report an error. If they are equal, assemble the parameters for the end node and return the result.

[0108] Sub-DAG execution algorithm

[0109] Notification sub-DAG and message sub-DAG

[0110] (1) Upon receiving the organization's confirmation notification, match the corresponding sub-DAG based on the HTTP address or parameters used for delivery;

[0111] (2) Extract the sequence number (orderNo) from the notification message according to the sub-dag configuration;

[0112] (3) Retrieve the node instance record data of the main dag based on the serial number orderNo and dagCode;

[0113] (4) Based on the mapping configuration of the associated message line of the sub-dag end node, send the associated message, and the driver will render the notification message into receipt data according to the receipt template;

[0114] (5) Upon receiving the receipt template, check whether the node instance record status has reached FINISH. If not, update the receipt data to the receipt field in the record of the main dag node instance; otherwise, exit the process directly.

[0115] (6) The driver checks whether the status of each node instance in the DAG has reached the FINISH state. If not, the process exits; if all nodes have reached the FINISH state, the process continues.

[0116] (7) Retrieve the sub-dag of the main dag end node. This sub-dag is used to send business messages. Assemble the previous receipt template into the final required business message. The message can be sent asynchronously in the form of MQ message. At this point, a complete processing flow is completed.

[0117] polling sub dag

[0118] (1) Asynchronously receive the associated message in step e of the third step of the main dag and drive the sub-dag to execute; the remaining steps are the same as the steps for notifying the sub-dag.

[0119] The data integration method and enterprise data management system according to the present invention have been described in detail above with reference to the accompanying drawings. The present invention simplifies the system's access to external services and data acquisition by setting up internal and external interfaces involved in external service transaction scenarios as nodes and thereby visually constructing the corresponding DAG (Directed Acyclic Graph). Furthermore, multiple external services can be integrated through the serial and parallel orchestration of intermediate nodes to provide more efficient and comprehensive service functions. In addition, through the master-child DAG mode, asynchronously executed child DAGs can obtain processing or compensation results not obtained during synchronous operations of the master DAG through polling or notification, ensuring data consistency.

[0120] Specifically, this invention improves the convenience and efficiency of external service access by using the visualization mode and node settings of DAG;

[0121] The problem of timeout and order loss can be solved by configuring master-child DAGs, which is especially suitable for the financial field with high requirements for data consistency, such as payment business;

[0122] It supports multi-node service orchestration, enabling subsequent nodes to obtain execution data from preceding nodes, and can orchestrate various interfaces of external service providers into new interfaces and output service capabilities.

[0123] It supports multiple communication protocols. Internal interfaces support RPC, MQ, HTTP, etc., while external interfaces support HTTP and SDK modes.

[0124] Furthermore, the method according to the present invention can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing the steps defined in the above-described method of the present invention.

[0125] Alternatively, the present invention can also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) storing executable code (or computer program, or computer instruction code) thereon, which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the various steps of the method described above according to the present invention.

[0126] Those skilled in the art will also understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both.

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for connecting transaction data, comprising: Select internal and external interfaces based on the target scenario of the transaction; Set the internal interface to correspond to the start node and the end node, and set the external interface to correspond to the middle node; Connect the start node, the middle node, and the end node to construct a directed acyclic graph (DAG) of the target scene. as well as When the target scenario is the payment scenario of the transaction, a sub-DAG is constructed for the intermediate nodes of the payment scenario DAG. The sub-DAG is used to asynchronously execute and return the operation results of the relevant operations of the intermediate nodes. In this process, the target scene request is sent as an input parameter to the target scene DAG, and the target scene DAG is executed to obtain the output result based on the external operation as the request feedback.

2. The method as described in claim 1, wherein, Constructing a sub-DAG for the intermediate nodes of a payment scenario DAG includes: Add a message line from the intermediate node to the start node of the sub-DAG, and add a message line from the end node of the sub-DAG to the intermediate node to construct a polling sub-DAG that is executed based on polling of the intermediate node. The associated message line is used to trigger the connection of the starting point's message to the ending point's operation.

3. The method as described in claim 1, wherein, Construct a sub-DAG for the intermediate nodes of the DAG in the payment scenario: The mechanism is set up to trigger the start node operation of the sub-DAG upon completion of operations related to intermediate nodes in the payment scenario DAG, and a related message line is added from the end node of the sub-DAG to the intermediate nodes of the payment scenario DAG to construct a message sub-DAG that is executed based on the completion of operations related to the intermediate nodes. The associated message line is used to trigger the connection of the starting point's message to the ending point's operation.

4. The method of claim 1, further comprising: A notification sub-DAG is constructed for the end node, which is used to assemble the operation result returned by the sub-DAG into an execution notification based on the notification template and return it to the internal interface.

5. The method of claim 1, wherein, Connecting the start node, the intermediate node, and the end node to construct the target scene DAG includes: Set the call input parameter template and call protocol for the intermediate node, and set the notification template for the end node. The parameters from the preceding node are placed into the input parameter template to obtain the call input parameters of the current intermediate node. The call protocol is used to implement the call to the external interface corresponding to the current intermediate node. The ending node generates the output result based on the notification template according to the input parameters of the preceding intermediate node.

6. The method of claim 1, wherein, The selection of internal and external interfaces depends on the target scenario of the transaction, including: Determine the multiple functional steps that need to be executed based on the target scenario; Select the required external interface for each functional step, and Connecting the start node, the intermediate node, and the end node to construct the target scene DAG includes: The external interfaces are set as serial intermediate nodes corresponding to the target scene DAG, and each serial intermediate node is connected one by one according to the functional steps.

7. The method of claim 1, wherein, The selection of internal and external interfaces depends on the target scenario of the transaction, including: Choose multiple external interfaces from different service providers to implement the same scenario functionality, and Connecting the start node, the intermediate node, and the end node to construct the target scene DAG includes: The multiple external interfaces are set as parallel intermediate nodes corresponding to the target scene DAG, and each is connected to the upstream and downstream nodes.

8. A transaction data docking DAG visualization generation device, used to execute the method as described in any one of claims 1-7 in a graphical user interface to construct a visualized target scene DAG.

9. An enterprise data management system, comprising: The DAG construction module is used to create multiple target scenarios involved in transactions with external systems, and to execute the transaction data docking method as described in any one of claims 1-7 for each target scenario to construct the corresponding target scenario DAG; The DAG execution module is used to execute the corresponding target scenario DAG when a target scenario request is received from an internal user, so as to return the request result to the user.

10. The system of claim 9, wherein, The DAG execution module is used for: The internal interface receives requests from users for the target scenario; The target scene request is sent as an input parameter into the target scene DAG; Execute the target scenario DAG and generate a request result based on the execution result of the external service; and The request result is returned to the user.

11. The system of claim 9, wherein, Executing the corresponding target scenario DAG includes: Traverse the target scene DAG to determine the nodes with an in-degree of 0 and obtain the context parameters and node configuration; Based on the obtained context parameters and node configuration, the corresponding operations for each node with an in-degree of 0 are executed in parallel. Add the node's execution result to the context and decrement the in-degree of its adjacent nodes by 1; and Repeat the above steps until the entire target scene DAG is completed.

12. The system of claim 11, wherein, Based on the obtained context parameters and node configuration, the operations corresponding to each node with an in-degree of 0 are executed in parallel, including: When the node configuration includes associated message lines, the driving parameters of the sub-DAG are generated according to the associated message configuration, and the asynchronous execution of the sub-DAG is driven; and The asynchronous execution result of the sub-DAG is obtained for the generation of the request result.

13. A computing device, comprising: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1 to 7.

14. A non-transitory machine-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1 to 7.

Images