Trading Engine

Abstract

Various examples relate to systems and methods for executing transactions in a hybrid computing environment. A batch trading engine may receive first transaction request data from a first trading platform application and select transaction description data describing multiple procedural operations for executing the first transaction. The batch trading engine may execute the first procedural operation at least in part by accessing a first backend system deployed and executed on a cloud platform, and execute a second procedural operation at least in part by accessing a second backend system executed by an on-premises computing system.

Description

Background Technology

[0001] Traditionally, software (including software used to manage businesses) is self-contained and runs on one or more local machines that constitute an on-premise computing system. Enterprises expecting to use software tools build on-premise computing systems and run software applications to deliver those tools on those systems. Cloud computing disrupts this model. Cloud computing allows enterprises to supplement or replace their on-premise computing systems with cloud software, platforms, and even computing infrastructure offered as services. Attached Figure Description

[0002] The disclosure is illustrated by way of example rather than limitation in the following figures.

[0003] Figure 1 This is a diagram illustrating an example of an arrangement for executing transactions in a hybrid computing environment.

[0004] Figure 2 It shows that it can be used Figure 1 A flowchart illustrating an example of the workflow executed by the volume trading engine.

[0005] Figure 3 This is a flowchart illustrating an example of the processing flow for executing transactions using a bulk trading engine.

[0006] Figure 4 It shows that it can be generated by Figure 1 A flowchart illustrating an example of the processing flow executed by the batch transaction engine.

[0007] Figure 5 It shows that it can be generated by Figure 1 A flowchart illustrating an example of the processing flow executed by the batch transaction engine.

[0008] Figure 6 This is a block diagram illustrating an example of a software architecture used in computing devices.

[0009] Figure 7 It is a block diagram of a machine in the example form of a computer system, in which instructions can be executed to cause the machine to perform any or more of the methods discussed herein. Detailed Implementation

[0010] Computing systems are deployed to execute and manage transactions, such as sales transactions in a business environment. For example, a Supplier Resource Management (SRM) system can manage transactions with a company's suppliers to procure raw materials and inventory. A Product Lifecycle Management (PLM) system can manage transactions and processes related to the lifecycle of goods or services, including, for example, the acquisition and transportation of raw materials, and the scheduling of manufacturing tasks. A Supply Chain Management (SCM) system can manage warehouse operations, including, for example, the movement of products and raw materials. A Customer Relationship Management (CRM) system can store and optimize the use of customer information and interactions. A sales system can manage transactions related to the sale of goods or services, such as placing orders, arranging delivery or shipment, and processing invoices. These and various other systems can be accessed or otherwise used to manage a company's transactions, including sales transactions.

[0011] In some examples, some or all of the software solutions and systems used to manage transactions are executed as on-premises software applications. On-premises software applications are typically executed by computing systems built by the enterprise, either on-premises or internally. An on-premises application can be implemented as a set of one or more executable files, libraries, etc., implemented by a set of executable files, libraries, etc., residing on the on-premises computing system. Users associated with the enterprise access the software application from the on-premises computing system.

[0012] When an enterprise uses on-premises applications running on its on-premises computing systems to maintain and execute enterprise transaction management, the coordination and communication between the various components are manageable. For example, the administrator user of the on-premises computing system can be responsible for (and have direct access to) all software applications, as well as the hardware used to run the software applications and store transaction data.

[0013] In some examples, it is desirable to perform some or all of the transaction management functions as a cloud application running in a cloud environment. A cloud environment includes one or more data centers that implement one or more virtual and / or hardware servers. For example, an instance of the cloud application may execute to provide software tools to a group of users (e.g., a group of users associated with an entity that has purchased access to the software tools). Each instance of the cloud application includes a set of one or more virtual machines and / or containers running in the cloud environment.

[0014] Cloud applications can offer various advantages to businesses. In some examples, cloud applications are implemented under the Software as a Service (SaaS) model, where the renter enterprise purchases access to the cloud application from the provider enterprise. This can limit or sometimes eliminate the renter enterprise's need to manage the implementation details of the application, such as, for example, managing processing and data storage hardware.

[0015] The increasing use of cloud applications by businesses adds complexity to transaction management. For example, businesses may implement transactions in distributed or hybrid computing environments, where some components of the transaction process flow execute in one location (such as an on-premises computing system), while other components execute in another location (such as a SaaS application implemented in a cloud environment). This can lead to increased communication and coordination between various on-premises and cloud-based applications. Consider an example where a business implements a sales system using an on-premises application and a CRM system using cloud leasing. Conducting sales transactions might involve querying and / or updating the CRM, as well as generating sales orders, for example, using the on-premises sales system.

[0016] In some examples, it may be desirable to implement the sales platform application in multiple locations across different computing systems. For instance, a first enterprise might expect one sales platform application to run on an on-premises computing system, and another sales platform application to run in the cloud. Furthermore, in some examples, it may be desirable for the enterprise to support partner enterprises that wish to sell the first enterprise's products or services. For example, a partner enterprise could run a sales platform application that can initiate and / or manage the first enterprise's sales transactions.

[0017] In distributed or hybrid sales transactions, setting up and modifying the transaction process can be challenging when two or more applications handling the transaction are implemented on different computing systems. For example, a sales platform application may coordinate with multiple on-premises and / or cloud-based components, increasing the complexity of the sales platform itself. Furthermore, when implementing multiple sales platform applications, each may be programmed to communicate and coordinate with multiple different and distributed components. This can create challenging scenarios when modifications to the transaction flow are desired, as altering the transaction flow may involve modifying multiple different sales platform applications.

[0018] Various examples utilize bulk transaction engines to address these and other challenges. A bulk transaction engine can communicate with one or more sales platform applications. Sales platform applications can send transaction requests to the bulk transaction engine via an application programming interface (API). The bulk transaction engine can execute multiple procedural operations to realize a transaction. Executing procedural operations may include communicating with various different components implemented on different computing systems, such as cloud environments and / or on-premises computing systems.

[0019] Figure 1This is a diagram illustrating an example of an arrangement 100 for executing transactions in a hybrid computing environment. Arrangement 100 includes a batch transaction engine 102 that communicates with various sales platform applications 106, 108, 110, and 112 via API 104. The batch transaction engine 102 can be implemented in any suitable computing environment, including, for example, a cloud environment and / or an on-premises computing system. Figure 1 In the example, the bulk transaction engine 102 includes various services, including orchestrator service 126, scheduler service 128, rule / process coordinator service 130, integration manager service 132, monitoring and auditing service 134, and support service 136.

[0020] The bulk trading engine 102 also communicates with various backend systems 114, 116, 118, 120, 122, and 124. These backend systems include cloud backend systems 114, 116, and 118, as well as on-premises backend systems 120, 122, and 124. Cloud backend systems 114, 116, and 118 include applications implemented in a cloud environment. In some examples, cloud backend systems 114, 116, and 118 include applications running in the same cloud environment as the bulk trading engine 102 and / or in different cloud environments. On-premises backend systems 120, 122, and 124 include applications running on one or more on-premises computing systems. In some examples, the bulk trading engine 102 communicates with on-premises backend systems 120, 122, and 124 via firewall 107. For example, firewall 107 may be implemented by an appropriate cloud connector application for connecting cloud-implemented applications to on-premises executed applications. Furthermore, although... Figure 1 Not shown, but in some examples, if cloud backend systems 114, 116, and 118 are executed in a different environment than the batch transaction engine 102, the batch transaction engine 102 can also utilize the firewall when communicating with the cloud backend systems 114, 116, and 118.

[0021] exist Figure 1 In the example, cloud backend systems 114, 116, and 118 include sales backend system 114, contract management backend system 116, and database backend system 118. However, it is understood that various other cloud backend systems (not shown) can be used for transaction processing. Furthermore, in Figure 1 In the example, the on-premises backend systems include sales backend system 120, contract management backend system 122, and database backend system 124, although various other on-premises backend systems may also be used.

[0022] Deployment 100 also includes various sales platform applications 106, 108, 110, and 112. Sales platform applications 106, 108, 110, and 112 can be implemented by enterprises selling goods and services and / or by partner enterprises. Sales platform applications 106, 108, 110, and 112 can be configured to interact with customer users 146 and / or salesperson users 148 to initiate sales or other transactions. Although Figure 1 The illustration shows a customer user 146 and a salesperson user 148; however, it is understood that multiple customer users 146 and / or multiple salesperson users 148 may utilize some or all of the various sales platform applications 106, 108, 110, and 112. Customer users 146 and salesperson users 148 may access sales platform applications 106, 108, 110, and 112 using user computing devices 150 and 152. User computing devices 150 and 152 may be or include any suitable computing device, such as, for example, a table computer, a mobile computing device, a laptop computer, a desktop computer, etc.

[0023] In some examples, one or more of sales platform applications 106, 108, 110, and 112 (via a user computing device such as user computing device 150) provide a customer user interface to one or more customer users 146. Customer users 146 can provide information about sales transactions, which may involve, for example, providing goods and / or services to customer users 146 or affiliated companies.

[0024] Furthermore, in some examples, some or all of the sales platform applications 106, 108, 110, and 112 provide a user interface to one or more salesperson users 148. Salesperson users 148 may be associated with the enterprise and / or other entities implementing the bulk transaction engine 102. Salesperson users 148 may access one or more of the sales platform applications 106, 108, 110, and 112 and provide customers with details of the goods and / or services offered for sale.

[0025] Sales platform applications 106, 108, 110, and 112 can generate transaction request data describing the requested transaction. For example, sales platform applications 106, 108, 110, and 112 can interact with customer user 146 and / or salesperson user 148 to receive instructions for a requested sales transaction. For example, a sales transaction may include the sale of goods and / or services to a customer (e.g., customer user 146 or other customers). Sales platform applications 106, 108, 110, and 112 can generate transaction request data based on interactions with customer users and / or salesperson users.

[0026] Sales platform applications 106, 108, 110, and 112 can provide transaction request data to API 104. The transaction request data describes the requested transaction. In some examples, sales platform applications 106, 108, and 110 are configured to format and / or schedule the transaction request data in a format readable by API 104. API 104 forwards the transaction request data to the bulk transaction engine 102.

[0027] The orchestrator service 126 can receive transaction request data and select transaction description data for execution. The transaction description data describes a set of procedural operations to be performed to realize the transaction. In some examples, the transaction description data is stored in backend systems 114, 116, 118, 120, 122, and 124. The orchestrator service 126 can be programmed to select the appropriate backend system 114, 116, 118, 120, 122, and 124 and query that backend system to obtain the transaction description data.

[0028] Integration Manager Service 132 can be programmed to connect to various backend systems 114, 116, 118, 120, 122, and 124 via an interface. For example, Orchestrator Service 126 can query Integration Manager Service 132 to access backend systems 114, 116, 118, 120, 122, and 124 that store transaction description data, prompting Integration Manager Service 132 to retrieve the transaction description data.

[0029] Integration Manager Service 132 can be programmed to have the implementation location and access details of each backend system 114, 116, 118, 120, 122, 124. For example, Integration Manager Service 132 can be programmed to interface with Firewall 107 (and / or the cloud connector application implementing Firewall 107) to access the on-premises backend systems 114, 116, 118, 120, 122, 124. Integration Manager Service 132 can also be programmed to interface with each cloud-implemented backend system 114, 116, 118.

[0030] Transaction description data can describe multiple process operations used to execute the requested transaction. Consider an example sales transaction. The first process operation might include accessing a CRM back-end system application to query customer data describing the customer for the requested transaction. If the customer data indicates that the customer is suitable for the transaction, the second process operation might involve accessing an accounting back-end system to generate an invoice. Other process operations might involve, for example, generating a bill to provide credit to the customer (if relevant), connecting to an SCM back-end system via an interface to prepare and / or schedule the manufacture of goods or services and / or the provision of services, etc. Orchestrator service 126 can coordinate the execution of these process operations.

[0031] Scheduler service 128 can generate schedules for the procedural operations used to execute transactions. Schedules can be generated before the procedural operations are executed and can include the scheduling times for some or all of the procedural operations. In some examples, the scheduling operation is executed after one procedural operation completes to determine the scheduling time for the next procedural operation.

[0032] In some examples, the monitoring and auditing service 134 monitors the execution of procedural operations within a transaction. For instance, upon completion of a procedural operation, the monitoring and auditing service 134 may generate object identifier data describing the completed procedural operation. The integration manager service 132 may write the object identifier data to persistent storage associated with the bulk trading engine 102. The persistent storage may be local persistent storage in the cloud or other environment implementing the bulk trading engine 102, and / or may reside in one or more of the backend systems 114, 116, 118, 120, 122, and 124. In some examples, the monitoring and auditing service 134 also generates object identifier data describing incomplete procedural operations (e.g., due to errors or other anomalies). The object identifier data describing incomplete procedural operations may also be written to persistent storage associated with the bulk trading engine 102.

[0033] The rule / process coordinator service 130 can communicate with the administrator user 144 via the user computing device 142. The user computing device 142 may be similar to user computing devices 150, 152. The administrator user 144 can provide process operation data 140, which provides a description of the process operation for a new transaction and / or the process operation for modifying an existing transaction. In some examples, the rule / process coordinator service 130 also provides the administrator user 144 with one or more notifications 138. Notifications 138 may indicate the status of a transaction, including, for example, whether the transaction was successful or failed.

[0034] Figure 2 It shows that it can be used Figure 1A flowchart of an example workflow 200 executed by the batch trading engine 102 is provided. In this example, the batch trading engine 102 executes a transaction comprising N procedural operations. The batch trading engine 102 (e.g., via orchestrator service 126 of integration manager service 132) retrieves transaction description data 202. The transaction description data 202 describes the procedural operations 1-N executed by the batch trading engine 102 to execute the transaction. In this example, the transaction description data 202 also describes notifications 204, 206. Notifications 204, 206 may be sent by the batch trading engine 102 to one or more administrator users 144 upon completion of a procedural operation and / or as described herein. For example, the transaction description data 202 may describe notification 204 to be sent to one or more administrator users 144 upon completion of procedural operation M, and notification 206 to be sent to one or more administrator users 144 upon completion of procedural operation N.

[0035] exist Figure 2 In the example, process operations 1, 2, M, and N are divided into sub-operations. For example, process operation 1 includes sub-operations 1.1 to 1.n. ​​Process operation 2 includes sub-operations 2.1 to 2.n. Process operation M includes sub-operations M.1 to Mn. Process operation N includes sub-operations N.1 to Nn.

[0036] exist Figure 2 In the example, each process operation involves one or more of the backend systems 114, 116, 118, 120, 122, and 124 (in... Figure 2 This is typically displayed as 216, where data is read from and / or written to. For example, some process operations may read data from backend systems 114, 116, 118, 120, 122, and 124. Consider an example process operation or sub-operation involving checking the backend CRM system to determine if a customer is suitable for a sales transaction. The bulk transaction engine can query the CRM system to receive a customer's past sales and / or payment records to determine if the customer is suitable for the requested sales transaction. The object identifier data for the process operation or sub-operation may include records read from the CRM system.

[0037] In some examples, a process operation or sub-operation generates process operation result data to be written to backend systems 114, 116, 118, and 120. Consider another example process operation or sub-operation that generates a sales order. This process operation or sub-operation can generate data describing the desired sales order and provide the sales order data to the appropriate backend system, which can then generate the sales order.

[0038] In some examples, for each process operation and / or sub-operation, transaction description data 202 may also describe which backend systems(s) will be associated with the process operation via an interface. After completing the interface connection with the backend systems, the bulk transaction engine 102 may generate object identifier data 208, 210, 212, and 214. Object identifier data 208, 210, 212, and 214 may describe the access to the backend systems. The integration manager service 132 may write the object identifier data 208, 210, 212, and 214 to persistent storage 216 associated with the bulk transaction engine 102, which may, for example, reside in one or more of the backend systems 114, 116, 118, and 120.

[0039] If an exception occurs during one or more of process operations 1-N, the batch transaction engine 102 can generate exception ticket data 218. Exception ticket data 218 can describe the exception, including, for example, the process operation and / or sub-operation in which the exception occurred. In some examples, exception ticket data 218 can indicate one or more backend systems accessed or to be accessed by the process operation and / or sub-operation that is the subject of the exception. Exception ticket data 218 can also be written to persistent storage 216.

[0040] Figure 3 This is a flowchart illustrating an example of a process flow 300 for executing transactions using the bulk transaction engine 102. In operation 302, the bulk transaction engine 102 is executed in a cloud environment. In some examples, the bulk transaction engine 102 is configured according to a microservices architecture. For example, the bulk transaction engine 102 is implemented by a collection of loosely coupled microservices executing in the cloud environment. Each microservice may also comprise a single executable file executing in a separate virtual machine (VM) or container implemented by the cloud environment. Individual microservices can be programmed to perform defined tasks or small sets of tasks and interact with other microservices in a defined manner (e.g., according to an application programming interface (API)). In some examples, the individual services 126, 128, 130, 132, 134, and 136 of the bulk transaction engine 102 are implemented as microservices. Executing the bulk transaction engine 102 may include spinning up one or more containers to execute one or more microservices or other components constituting the bulk transaction engine 102.

[0041] In operation 304, the batch transaction engine 102 receives transaction request data describing the first transaction. The transaction request data may, for example, come from a sales platform application (such as...). Figure 1 The sales platform application 106, 108, 110, or 112 receives the transaction request data. In operation 306, the bulk transaction engine 102 (e.g., its orchestrator service 126) uses the transaction request data to select the transaction description data for the transaction.

[0042] In operation 308, the bulk trading engine 102 executes a first procedural operation of the transaction (e.g., as described by the transaction description data). Executing the procedural operation may include (e.g., using the integration manager service 132) interacting with one or more backend systems 309. In operation 310, the bulk trading engine 102 (e.g., the integration manager service 132) writes object identifier data to persistent storage associated with the bulk trading engine 102. The object identifier data describes the interaction between the bulk trading engine 102 and the associated backend system 309 during the execution of the procedural operation. As described herein, interaction with the backend system may include one or more read operations and / or one or more write operations. Furthermore, in some examples, executing the procedural operation may include interaction with more than one backend system 309. In these examples, the integration manager service 132 may generate and store multiple instances of object identifier data, and / or may generate and store object identifier data describing interactions with more than one backend system 309.

[0043] In operation 312, the batch trading engine 102 determines whether the transaction description data includes additional procedural operations. If so, in operation 308, the batch trading engine 102 can execute the next procedural operation. If there are no further procedural operations in the transaction, in operation 314, the batch trading engine 102 can wait for the next transaction.

[0044] Figure 4 It shows that it can be generated by Figure 1 A flowchart of an example of a process flow 400 executed by a batch trading engine 102 (e.g., its monitoring and auditing service 134) to monitor process operations of a transaction. In operation 402, the batch trading engine 102 (e.g., its monitoring and auditing service 134) determines the scheduling time for at least one process operation of a transaction. The scheduling time indicates, for example, the time when the process operation is expected or scheduled to complete. In some examples, determining the scheduling time of a process operation includes the generation scheduling time of one or more sub-operations of the process operation.

[0045] In some examples, operation 402 is performed for a single process operation and / or multiple process operations. In some examples, the batch trading engine 102 may generate the scheduling time for each process operation of a transaction before or near the time when the batch trading engine 102 begins executing the transaction. In some examples, the batch trading engine 102 generates the scheduling time for the process operation after the previous process operation has completed.

[0046] In operation 404, the batch trading engine 102 (e.g., its monitoring and auditing service 134) determines whether the first process operation of the transaction was completed as scheduled. If the first process operation was completed as scheduled, then in operation 408, the batch trading engine 102 can consider the next operation. In some examples, the batch trading engine 102 (e.g., its monitoring and auditing service 134) can return to operation 402 and determine the scheduling time for the next process operation. If, in some examples, the batch trading engine 102 has already generated the scheduling time for the next process operation, then in operation 404, the batch trading engine 102 can determine whether the next process operation of the transaction was completed as scheduled.

[0047] If, in operation 404, the bulk transaction engine 102 (e.g., its monitoring and auditing service 134) determines that the transaction's process operation did not complete as scheduled, then in operation 406, the bulk transaction engine 102 may generate and write anomalous ticket data. The anomalous ticket data may be written to persistent storage associated with the bulk transaction engine 102 as described herein.

[0048] In various examples, the bulk transaction engine 102 utilizes audit data generated during the failed transaction to re-execute the failed transaction. Audit data may include exception ticket data and / or object identifier data. Figure 5 It shows that it can be generated by Figure 1 A flowchart of an example of the process flow 500 in which the batch transaction engine 102 executes to re-execute previously failed transactions.

[0049] In operation 502, the batch transaction engine 102 receives an instruction to re-execute failed transactions. This instruction may be generated by the sales platform applications 106, 108, 110, and 112 that initially requested the transaction, and / or may be automatically generated in response to the failure of a failed transaction. In operation 504, the batch transaction engine 102 accesses audit data describing the failed transactions. The audit data may include, for example, object identifier data written after a successful completion of a process operation and / or sub-operation, and / or exception ticket data describing one or more failed process operations or sub-operations.

[0050] In operation 506, by using audit data, the bulk trading engine 102 can select the process operations to be executed. For example, the bulk trading engine 102 may not re-execute some or all of the process operations of a previously successfully executed transaction (e.g., as indicated by object identifier data). In some examples, the bulk trading engine 102 can select a first process operation that was previously unsuccessfully executed (e.g., as indicated by object identifier data and exception ticket data). In some examples, the bulk trading engine 102 can select a sub-operation of a previously failed operation, where the sub-operation is the first sub-operation that was unsuccessfully completed in a previous execution of the transaction.

[0051] In operation 508, the bulk trading engine 102 executes the procedural operation selected in operation 506. This may include interaction with one or more backend systems 509. In operation 510, the bulk trading engine 102 (e.g., Integration Manager service 132) writes object identifier data to persistent storage associated with the bulk trading engine 102. The object identifier data describes the interaction between the bulk trading engine 102 and the associated backend system 509 during the execution of the procedural operation.

[0052] In operation 512, the batch trading engine 102 determines whether the transaction description data includes additional procedural operations. If so, in operation 508, the batch trading engine 102 can execute the next procedural operation. If there are no further procedural operations in the transaction, in operation 514, the batch trading engine 102 can wait for the next transaction.

[0053] In view of the above disclosure, various examples are listed below. It should be noted that one or more features of the examples, whether viewed in isolation or in combination, should be considered within the scope of the disclosure of this application.

[0054] Example:

[0055] Example 1 is a system comprising: a cloud platform deployment programmed to execute a batch trading engine to perform operations, the operations including: receiving first transaction request data from a first trading platform application, the first transaction request data describing a first transaction; selecting transaction description data describing a plurality of procedural operations for executing the first transaction, the transaction description data describing a first procedural operation and a second procedural operation; executing the first procedural operation, the execution of the first procedural operation including accessing a first backend system executed on the cloud platform deployment; writing first object identifier data to persistent storage associated with the batch trading engine, the first object identifier data describing the access to the first backend system; executing a second procedural operation, the execution of the second procedural operation including accessing a second backend system executed by an on-premises computing system; and writing second object identifier data to persistent storage associated with the batch trading engine, the second object identifier data describing the access to the first backend system.

[0056] In Example 2, the subject matter of Example 1 may optionally include: wherein the batch trading engine further includes a scheduler service, and wherein the transaction description data further describes a third process operation and a fourth process operation, the operations further including: the scheduler service determining the scheduling time of the third process operation and the scheduling time of the fourth process operation; the batch trading engine executing the third process operation; the scheduler service determining that the third process operation cannot be completed before the scheduling time of the fourth process operation; and writing abnormal ticket data to persistent storage associated with the batch trading engine, the abnormal ticket data describing the third process operation and the fourth process operation.

[0057] In Example 3, the subject matter of Example 2 may optionally include: the operation further includes: receiving a request to re-execute the first transaction by the batch trading engine; accessing first object identifier data, second object identifier data, and exception ticket data by the batch trading engine; using the first object identifier data, second object identifier data, and exception ticket data by the batch trading engine to select a third process operation to be performed; and performing the third process operation by the batch trading engine.

[0058] In Example 4, any one or more of the topics in Examples 1 to 3 may optionally include: the first transaction request data is received by the bulk trading engine via the trading engine's application programming interface (API).

[0059] In Example 5, the subject of any one or more of Examples 1 to 4 may optionally include: the operation further includes: receiving second transaction request data from a second trading platform application by a bulk trading engine, the second transaction request data describing the second transaction.

[0060] In Example 6, the subject of any one or more of Examples 1 to 5 may optionally include: the operation further includes a process coordinator service, the operation further includes: receiving input data from an administrator user by the process coordinator service; and generating transaction data by the process coordinator service based at least in part on the input data.

[0061] In Example 7, the subject of any one or more of Examples 1 to 6 may optionally include: the operation further includes: receiving updated data from an administrator user by a process coordinator service, the updated data describing changes to at least one of a first process operation or a second process operation; and modifying transaction data by the process coordinator service based at least in part on the updated data.

[0062] In Example 8, the subject of any one or more of Examples 1 to 7 may optionally include: the execution of a first process operation producing first process operation result data, and access to a first backend system including writing the first process operation result data to the first backend system.

[0063] In Example 9, any one or more of the topics in Examples 1 to 8 may optionally include: access to the second backend system includes reading operational data from the second backend system.

[0064] Example 10 is a method for executing transactions in a hybrid computing environment, the method comprising: executing a batch transaction engine in a cloud platform deployment, the batch transaction engine including an orchestrator service and an integration manager service; receiving first transaction request data from a first transaction platform application by the batch transaction engine, the first transaction request data describing a first transaction; selecting transaction description data by the orchestrator service describing a plurality of procedural operations for executing the first transaction, the transaction description data describing a first procedural operation and a second procedural operation; executing the first procedural operation by the batch transaction engine, the execution of the first procedural operation including accessing a first backend system executed in the cloud platform deployment; writing first object identifier data to persistent storage associated with the batch transaction engine by the integration manager service, the first object identifier data describing access to the first backend system; executing a second procedural operation by the batch transaction engine, the execution of the second procedural operation including accessing a second backend system executed by an on-premises computing system; and writing second object identifier data to persistent storage associated with the batch transaction engine by the integration manager service, the second object identifier data describing access to the first backend system.

[0065] In Example 11, the subject of Example 10 may optionally include: wherein the batch trading engine further includes a scheduler service, and wherein the transaction description data further describes a third process operation and a fourth process operation, the method further including: the scheduler service determining the scheduling time of the third process operation and the scheduling time of the fourth process operation; the batch trading engine executing the third process operation; the scheduler service determining that the third process operation cannot be completed before the scheduling time of the fourth process operation; and writing abnormal ticket data to persistent storage associated with the batch trading engine, the abnormal ticket data describing the third process operation and the fourth process operation.

[0066] In Example 12, the subject of Example 11 may optionally include: receiving a request to re-execute the first transaction by the bulk transaction engine; accessing the first object identifier data, the second object identifier data, and the exception ticket data by the orchestrator service; using the first object identifier data, the second object identifier data, and the exception ticket data by the orchestrator service to select a third process operation for execution; and executing the third process operation by the bulk transaction engine.

[0067] In Example 13, any one or more of the topics in Examples 10 to 12 may optionally include: the first transaction request data is received by the orchestrator service via the application programming interface (API) of the transaction engine.

[0068] In Example 14, the subject of any one or more of Examples 10 to 13 may optionally include: receiving second transaction request data from a second trading platform application by a bulk trading engine, the second transaction request data describing the second transaction.

[0069] In Example 15, the subject matter of any one or more of Examples 10 to 14 may optionally include: the bulk transaction engine also includes a process coordinator service, and the method further includes: receiving input data from an administrator user by the process coordinator service; and generating transaction description data by the process coordinator service based at least in part on the input data.

[0070] In Example 16, the subject matter of any one or more of Examples 10 to 15 may optionally include: receiving updated data from an administrator user by the process coordinator service, the updated data describing changes to at least one of the first process operation or the second process operation; and modifying transaction description data by the process coordinator service based at least in part on the updated data.

[0071] In Example 17, the subject of any one or more of Examples 10 to 16 may optionally include: the execution of a first process operation producing first process operation result data, and access to a first backend system including writing the first process operation result data to the first backend system.

[0072] In Example 18, any one or more of the topics in Examples 10 to 17 may optionally include: access to the second backend system includes reading operational data from the second backend system.

[0073] Example 19 is a non-transitory machine-readable medium having instructions thereon, which, when executed by at least one processor, cause at least one processor to perform operations, said operations including: executing a batch transaction engine in a cloud platform deployment, the batch transaction engine including an orchestrator service and an integration manager service; receiving first transaction request data from a first transaction platform application, the first transaction request data describing a first transaction; selecting transaction description data describing a plurality of procedural operations for executing the first transaction, the transaction description data describing a first procedural operation and a second procedural operation; executing the first procedural operation, the execution of the first procedural operation including accessing a first backend system executed in the cloud platform deployment; writing first object identifier data to persistent storage associated with the batch transaction engine, the first object identifier data describing access to the first backend system; executing a second procedural operation, the execution of the second procedural operation including accessing a second backend system executed by an on-premises computing system; and writing second object identifier data to persistent storage associated with the batch transaction engine, the second object identifier data describing access to the first backend system.

[0074] In Example 20, the subject matter of Example 19 may optionally include: wherein the batch trading engine further includes a scheduler service, and wherein the transaction description data further describes a third process operation and a fourth process operation, the operations further including: the scheduler service determining the scheduling time of the third process operation and the scheduling time of the fourth process operation; the batch trading engine executing the third process operation; the scheduler service determining that the third process operation cannot be completed before the scheduling time of the fourth process operation; and writing abnormal ticket data to persistent storage associated with the batch trading engine, the abnormal ticket data describing the third process operation and the fourth process operation.

[0075] Figure 6 This is a block diagram 600 illustrating an example of a software architecture 602 for a computing device. Architecture 602 can be used in conjunction with various hardware architectures (e.g., as described herein). Figure 6 This is merely a non-limiting example of a software architecture, and many other architectures can be implemented to facilitate the functionality described herein. A representative hardware layer 604 is shown, and it can represent any of the computing devices described above, for example. In some examples, hardware layer 604 can be configured according to… Figure 6 It is implemented through the architecture of computer systems.

[0076] A representative hardware layer 604 includes one or more processing units 606 having associated executable instructions 608. The executable instructions 608 represent executable instructions of the software architecture 602 (including implementations of the methods, modules, subsystems, and components described herein), and may also include memory and / or storage modules 610, which also have the executable instructions 608. Hardware layer 604 may also include other hardware indicated by other hardware 612, which represents any other hardware of hardware layer 604, such as other hardware shown as part of architecture 602.

[0077] exist Figure 6 In the example architecture, software architecture 602 can be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 602 may include layers such as operating system 614, libraries 616, framework / middleware 618, applications 620, and presentation layer 644. Operationally, application 620 and / or other components within each layer can invoke API calls 624 through the software stack and, in response to API calls 624, access responses, return values, etc., as shown in message 626. The layers shown are representative in nature, and not all software architectures have all layers. For example, some mobile or dedicated operating systems may not provide a framework / middleware layer 618, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.

[0078] Operating system 614 can manage hardware resources and provide common services. Operating system 614 may include, for example, a kernel 628, services 630, and drivers 632. Kernel 628 can act as an abstraction layer between hardware and other software layers. For example, kernel 628 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Services 630 can provide other common services from other software layers. In some examples, service 630 includes interrupt services. Interrupt services can detect the receipt of an interrupt and, in response, cause architecture 602 to suspend its current processing and execute an interrupt service routine (ISR) when the interrupt is accessed.

[0079] Driver 632 can be responsible for controlling or connecting to underlying hardware via an interface. For example, driver 632 may include display drivers, camera drivers, etc. Drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, NFC drivers, audio drivers, power management drivers, etc., depend on the hardware configuration.

[0080] Library 616 provides common infrastructure that can be utilized by application 620 and / or other components and / or layers. Library 616 typically provides functionality that allows other software modules to perform tasks more easily than by directly interfaced with the underlying operating system 614 functions (e.g., kernel 628, services 630, and / or drivers 632). Library 616 may include system libraries 634 (e.g., the C standard library) that provide functions such as memory allocation, string manipulation, mathematical functions, etc. Furthermore, library 616 may include API libraries 636, such as media libraries (e.g., libraries supporting the rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., OpenGL frameworks for rendering 2D and 3D graphical content on a display), database libraries (e.g., SQLite providing various relational database functions), network libraries (e.g., WebKit providing web browsing functionality), etc. Library 616 may also include a wide variety of other libraries 638 that provide many other APIs to application 620 and other software components / modules.

[0081] Framework 618 (sometimes also called middleware) can provide higher-level common infrastructure that can be utilized by application 620 and / or other software components / modules. For example, framework 618 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. Framework 618 can provide various other APIs that can be utilized by application 620 and / or other software components / modules, some of which may be specific to a particular operating system or platform.

[0082] Application 620 includes built-in application 640 and / or third-party application 642. Representative examples of built-in application 640 may include, but are not limited to, contact applications, browser applications, book reader applications, location applications, median applications, messaging applications, and / or game applications. Third-party application 642 may include any built-in application 640 as well as a wide range of other applications. In a specific example, third-party application 642 (e.g., applications used by entities other than a platform-specific vendor of Android) TM Or iOS TM Applications developed using a Software Development Kit (SDK) can run on mobile operating systems such as iOS. TM Android TM , Mobile software running on a phone or other mobile computing device operating system. In this example, a third-party application 642 can invoke API calls 624 provided by the mobile operating system (such as operating system 614) to facilitate the functionality described herein.

[0083] Application 620 can utilize built-in operating system functions (e.g., kernel 628, services 630, and / or drivers 632), libraries (e.g., system libraries 634, API libraries 636, and other libraries 638), and frameworks / middleware 618 to create a user interface for interacting with the system's user. Alternatively or additionally, in some systems, user interaction may occur through a presentation layer, such as presentation layer 644. In these systems, the "logic" of the application / module can be separated from the aspects of the application / module that interact with the user.

[0084] Some software architectures utilize virtual machines. Figure 6 In this example, it is illustrated using virtual machine 648. The virtual machine creates a software environment in which applications / modules can execute as if they were running on a hardware computing device. The virtual machine is hosted by a host operating system (operating system 614) and typically (though not always) has a virtual machine monitor 646, which manages the operation of virtual machine 648 and interfaces with the host operating system (i.e., operating system 614). The software architecture executes within virtual machine 648 (such as operating system 650, libraries 652, frameworks / middleware 654, applications 656, and / or presentation layers 658). These layers of the software architecture executing within virtual machine 648 may be the same as the corresponding layers described previously, or they may be different.

[0085] Modules, components and logic

[0086] In this document, specific embodiments are described as including logic or a number of components, modules, or mechanisms. A module may constitute a software module (e.g., containing (1) code on a non-transitory machine-readable medium or (2) in a transmitted signal) or a module implemented in hardware. A hardware-implemented module is a tangible unit capable of performing a specific operation and may be configured or arranged in a specific manner. In example embodiments, one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform the specific operations described herein.

[0087] In various embodiments, the hardware-implemented modules can be implemented mechanically or electronically. For example, a hardware-implemented module may include dedicated circuitry or logic permanently configured to perform a specific operation (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware-implemented module may also include programmable logic or circuitry temporarily configured by software to perform a specific operation (e.g., contained within a general-purpose processor or another programmable processor). It should be understood that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured (e.g., software-configured) circuitry, may be driven by cost and time considerations.

[0088] Therefore, the term "hardware-implemented module" should be understood to include tangible entities, whether physically constructed, permanently configured (e.g., hardwired), or temporarily or transitionally configured (e.g., programmed), to operate in a particular manner and / or perform the specific operations described herein. Considering embodiments where hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules does not need to be configured or instantiated at any given time. For example, in cases where the hardware-implemented modules include a general-purpose processor configured using software, the general-purpose processor can be configured as its own distinct hardware-implemented module at different times. The software can accordingly configure the processor, for example, to constitute a specific hardware-implemented module at one time and different hardware-implemented modules at different times.

[0089] Hardware-implemented modules can provide information to and receive information from other hardware-implemented modules. Therefore, the described hardware-implemented modules can be considered communication-coupled. In the presence of multiple such hardware-implemented modules simultaneously, communication can be achieved through signal transmission (e.g., on appropriate circuitry and buses connecting the hardware-implemented modules). In embodiments where multiple hardware-implemented modules are configured or instantiated at different times, communication between these modules can be achieved, for example, through the storage and retrieval of information in a memory structure accessible to the multiple hardware-implemented modules. For example, one hardware-implemented module can perform an operation and store the output of that operation in a memory device communicationally coupled to it. Another hardware-implemented module can then access the memory device at a later time to retrieve and process the stored output. Hardware-implemented modules can also initiate communication with input or output devices and operate on resources (e.g., collections of information).

[0090] The various operations of the example methods described herein can be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the relevant operations. Whether temporarily or permanently configured, these processors can constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the modules mentioned herein may include processor-implemented modules.

[0091] Similarly, the methods described herein can be implemented at least in part by a processor. For example, at least some operations of the methods can be performed by one or more processors or modules implemented by processors. The execution of a particular operation can be distributed among one or more processors, residing not only within a single machine but also deployed across several machines. In some example embodiments, one or more processors may be located in a single location (e.g., in a home environment, office environment, or server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0092] One or more processors may also operate in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the execution of related operations. For example, at least some operations may be performed by a group of computers (as an example of a machine that includes processors), and these operations may be accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

[0093] Electronic devices and systems

[0094] The example embodiments can be implemented using digital electronic circuits, computer hardware, firmware, or software, or a combination thereof. The example embodiments can be implemented using computer program products (e.g., computer programs tangibly contained in an information carrier), for example, in a machine-readable medium for execution or control of the operation of a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers).

[0095] Computer programs can be written in any programming language (including compiled or interpreted languages) and can be deployed in any form, including as standalone programs or as modules, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected through a communication network.

[0096] In the example embodiments, the operations may be performed by one or more programmable processors, which execute computer programs to perform functions by manipulating input data and generating output. The method operations may also be performed by dedicated logic circuitry (e.g., an FPGA or ASIC), and the apparatus of the example embodiments may be implemented as dedicated logic circuitry.

[0097] Computing systems may include clients and servers. Clients and servers are generally geographically isolated and typically interact via communication networks. The client-server relationship arises from computer programs running on their respective computers and having a client-server relationship with each other. In embodiments where a programmable computing system is deployed, it should be understood that both hardware and software architectures are worth considering. Specifically, it should be understood that the choice of implementing a particular function in permanently configured hardware (e.g., ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware can be a design choice. The following lists the hardware (e.g., machines) and software architectures that can be deployed in various example embodiments.

[0098] Example machine architecture and machine-readable media

[0099] Figure 7This is a block diagram of a machine in the example form of computer system 700, in which instructions 724 can be executed to cause the machine to perform any or more methods discussed herein. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate as a server or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, network appliance, network router, switch, or bridge, or any machine capable of executing instructions (in turn or otherwise) specifying actions to be taken by the machine. Furthermore, although only a single machine is shown, the term "machine" should also be considered to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more methods discussed herein.

[0100] Example computer system 700 includes processors 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), main memory 704, and static memory 706 that communicate with each other via bus 708. Computer system 700 may also include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 700 also includes an alphanumeric input device 712 (e.g., a keyboard or touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device 714 (e.g., a mouse), a disk drive unit 716, a signal generation device 718 (e.g., a speaker), and a network interface device 720.

[0101] Machine-readable media

[0102] The disk drive unit 716 includes a machine-readable medium 722 on which one or more sets of data structures and instructions 724 (e.g., software) are stored, the set of data structures and instructions 724 containing, or being utilized by, any one or more methods or functions described herein. Where main memory 704 and processor 702 also constitute the machine-readable medium 722, the instructions 724 may also reside wholly or at least partially in main memory 704, and / or, during execution by computer system 700, reside wholly or at least partially in processor 702.

[0103] Although machine-readable medium 722 is shown as a single medium in the example embodiment, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instructions 724 or data structures. The term "machine-readable medium" should also be considered to include any tangible medium capable of storing, encoding, or carrying instructions 724 for machine execution and causing the machine to perform any one or more methods of this disclosure, or any tangible medium capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 724. The term "machine-readable medium" should accordingly include, but is not limited to, solid-state memory and optical and magnetic media. Specific examples of machine-readable medium 722 include non-volatile memory, for example including: semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0104] transmission medium

[0105] Furthermore, instruction 724 can be transmitted or received on communication network 726 using a transmission medium. Instruction 724 can be transmitted using network interface device 720 and any of several well-known transmission protocols (e.g., HTTP). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, mobile phone networks, conventional telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term "transmission medium" should be considered to include any intangible medium capable of storing, encoding, or carrying instructions 724 for machine execution, and includes digital or analog communication signals or other intangible media to facilitate communication of such software.

[0106] Although embodiments have been described with reference to specific exemplary examples, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of this disclosure. Therefore, this specification and the accompanying drawings should be considered in an illustrative rather than restrictive sense. The accompanying drawings, which form a part of this document, illustrate specific embodiments in which the subject matter may be practiced in an illustrative rather than restrictive manner. The illustrated embodiments have been described in sufficient detail to enable those skilled in the art to implement the teachings disclosed herein. Other embodiments may be utilized, and from which it is derived that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Therefore, this detailed description should not be construed as restrictive, and the scope of the various embodiments is defined only by the appended claims and all their equivalents.

[0107] For convenience, these embodiments of the subject matter of this invention may be referred to individually and / or collectively as the term "invention" herein, and the disclosure of more than one invention or inventive concept does not imply a voluntary limitation of the scope of this application to any single invention or inventive concept. Therefore, although specific embodiments have been shown and described herein, it should be understood that arrangements intended to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of the various embodiments. Those skilled in the art will recognize, upon reviewing the above description, combinations of the above embodiments and other embodiments not specifically described herein.

Claims

1. A system for executing transactions in a hybrid computing environment, comprising: A cloud platform is deployed and programmed to execute a batch trading engine to perform operations, the batch trading engine including an orchestrator service and an integration manager service, the operations including: The batch trading engine receives first transaction request data from a first trading platform application, the first transaction request data describing the first transaction, and receives second transaction request data from a second trading platform application, the second transaction request data describing the second transaction; The orchestrator service selects transaction description data that describes multiple procedural operations used to execute the first transaction. The transaction description data describes the first procedural operation and the second procedural operation. The scheduler service of the batch trading engine generates the scheduling time for the first process operation and the scheduling time for the second process operation. The first process operation is executed by the batch transaction engine. The execution of the first process operation includes accessing a first backend system deployed and executed on the cloud platform. The execution of the first process operation generates first process operation result data. The access to the first backend system includes writing the first process operation result data into the first backend system. The integration manager service writes the first object identifier data to persistent storage associated with the bulk transaction engine. The first object identifier data describes the access to the first backend system. The second process operation is executed by the batch transaction engine. The execution of the second process operation includes accessing a second back-end system executed by an on-premises computing system. Access to the second back-end system includes reading operation data from the second back-end system. The Integration Manager service writes the second object identifier data to persistent storage associated with the bulk transaction engine; this second object identifier data describes access to the second backend system; and The batch transaction engine also includes a process coordinator service. The process coordinator service receives input data from the administrator user and generates transaction description data based on the input data, at least in part; or The process coordinator service receives updated data from the administrator user, the updated data describing changes to at least one of the first process operation or the second process operation, and the process coordinator service modifies the transaction description data at least in part based on the updated data.

2. The system according to claim 1, wherein, The batch trading engine also includes a scheduler service, and wherein the transaction description data further describes third and fourth process operations, which include: The scheduling time for the third process operation and the scheduling time for the fourth process operation are determined by the scheduler service. The third process is executed by the batch trading engine; The scheduler service determines that the third process operation cannot be completed before the scheduling time of the fourth process operation; and Abnormal ticket data is written to persistent storage associated with the bulk transaction engine. The abnormal ticket data describes the third and fourth process operations.

3. The system according to claim 2, wherein the operation further includes: The batch trading engine receives a request to re-execute the first transaction; The batch transaction engine accesses the first object identifier data, the second object identifier data, and the exception ticket data. The batch transaction engine uses the first object identifier data, the second object identifier data, and the exception ticket data to select the third process operation to be executed; as well as The third process is executed by the batch transaction engine.

4. In the system according to any one of claims 1-3, the first transaction request data is received by the batch trading engine via the application programming interface (API) of the trading engine.

5. A method for executing transactions in a hybrid computing environment, the method comprising: The batch transaction engine is executed in the cloud platform deployment. The batch transaction engine includes the orchestrator service and the integration manager service. The batch trading engine receives first transaction request data from a first trading platform application, the first transaction request data describing the first transaction, and receives second transaction request data from a second trading platform application, the second transaction request data describing the second transaction; The orchestrator service selects transaction description data that describes multiple procedural operations used to execute the first transaction. The transaction description data describes the first procedural operation and the second procedural operation. The scheduler service of the batch trading engine generates the scheduling time for the first process operation and the scheduling time for the second process operation. The first process operation is executed by the batch transaction engine. The execution of the first process operation includes accessing a first backend system deployed and executed on the cloud platform. The execution of the first process operation generates first process operation result data. The access to the first backend system includes writing the first process operation result data into the first backend system. The integration manager service writes the first object identifier data to persistent storage associated with the bulk transaction engine. The first object identifier data describes the access to the first backend system. The second process operation is executed by the batch transaction engine. The execution of the second process operation includes accessing a second back-end system executed by an on-premises computing system. Access to the second back-end system includes reading operation data from the second back-end system. The Integration Manager service writes the second object identifier data to persistent storage associated with the bulk transaction engine; this second object identifier data describes access to the second backend system; and The batch transaction engine also includes a process coordinator service, and the method further includes: The process coordinator service receives input data from the administrator user and generates transaction description data based on the input data, at least in part; or The process coordinator service receives updated data from the administrator user, the updated data describing changes to at least one of the first process operation or the second process operation, and the process coordinator service modifies the transaction description data at least in part based on the updated data.

6. The method according to claim 5, wherein, The batch trading engine also includes a scheduler service, and the transaction description data further describes third and fourth process operations. The method also includes: The scheduling time for the third process operation and the scheduling time for the fourth process operation are determined by the scheduler service. The third process is executed by the batch trading engine; The scheduler service determines that the third process operation cannot be completed before the scheduling time of the fourth process operation; and Abnormal ticket data is written to persistent storage associated with the bulk transaction engine. The abnormal ticket data describes the third and fourth process operations.

7. The method according to claim 6, further comprising: The batch trading engine receives a request to re-execute the first transaction; The orchestrator service accesses the first object identifier data, the second object identifier data, and the exception ticket data. The orchestrator service uses the first object identifier data, the second object identifier data, and the exception ticket data to select the third process operation to be performed; as well as The third process is executed by the batch transaction engine.

8. The method according to any one of claims 5-7, wherein the first transaction request data is received by the orchestrator service via the application programming interface (API) of the transaction engine.

9. A non-transitory machine-readable medium having instructions thereon, the instructions, when executed by at least one processor, causing at least one processor to perform an operation, said operation comprising: The batch transaction engine is executed in the cloud platform deployment. The batch transaction engine includes the orchestrator service and the integration manager service. The batch trading engine receives first transaction request data from a first trading platform application, the first transaction request data describing the first transaction, and receives second transaction request data from a second trading platform application, the second transaction request data describing the second transaction; Select transaction description data that describes multiple procedural operations used to execute the first transaction; the transaction description data describes the first procedural operation and the second procedural operation. The scheduler service of the batch trading engine generates the scheduling time for the first process operation and the scheduling time for the second process operation. Executing a first process operation, the execution of the first process operation includes accessing a first backend system deployed and executed on a cloud platform, wherein the execution of the first process operation generates first process operation result data, and the access to the first backend system includes writing the first process operation result data into the first backend system. Write the first object identifier data to persistent storage associated with the bulk transaction engine. The first object identifier data describes the access to the first backend system. Executing a second process operation, the execution of which includes accessing a second back-end system executed by an on-premises computing system, and accessing the second back-end system including reading operation data from the second back-end system; Write the second object identifier data to persistent storage associated with the bulk transaction engine; the second object identifier data describes the access to the second backend system; and The batch trading engine's process coordinator service receives input data from the administrator user and generates transaction description data based, at least in part, on the input data; or The process coordinator service receives updated data from the administrator user, the updated data describing changes to at least one of the first process operation or the second process operation, and the process coordinator service modifies the transaction description data at least in part based on the updated data.

10. The medium according to claim 9, wherein, The batch trading engine also includes a scheduler service, and the transaction description data further describes third and fourth process operations, which include: The scheduling time for the third process operation and the scheduling time for the fourth process operation are determined by the scheduler service. The third process is executed by the batch trading engine; The scheduler service determines that the third process operation cannot be completed before the scheduling time of the fourth process operation; and Abnormal ticket data is written to persistent storage associated with the bulk transaction engine. The abnormal ticket data describes the third and fourth process operations.

Images