Handling failed database transaction records

Abstract

A database transaction record received for delivery of data to a database can be associated with one or more validation tasks. When one of the validation tasks fails, a fault is detected and processing of the transaction record is aborted. Instead of terminating the transaction record and requiring the submission system to reinitiate the processing, the system can use a mapping table to determine if it is possible to automatically resubmit. A new transaction record can be generated that replicates the invocation context from the original transaction record, and portions of the transaction payload can be copied to the new transaction record along with changes that ensure the new transaction record will pass the validation tasks. The new transaction record can then be submitted through the same interface that received the original transaction record, and the original transaction record can be removed from the transaction data store.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. Patent Application No. 16 / 780,862, filed February 3, 2020, entitled “HANDLING FAULTED DATABASETRANSACTION RECORDS,” which is incorporated herein by reference in its entirety. Background Technology

[0003] A database transaction represents a process performed on a database within a database management system (DBMS). A transaction is typically represented by a transaction record, which details various aspects of a request to make one or more changes to the database, including the values ​​to be changed, the tables to be accessed, and other descriptive information. Within a DBMS, a transaction record can generate multiple operations performed on multiple tables. However, a transaction as a whole can be represented by a transaction record as a single, atomic, consistent, isolated, and durable process.

[0004] To prevent unauthorized or incorrect transaction records from being submitted to the database, some transaction records may include one or more validations that can be performed on the transaction record before allowing the database to deliver it. These validations may include receiving authorization from attached systems / users, and validation rules performed on the values ​​in the transaction record. When a transaction record fails validation, the database management system prevents the transaction record from being delivered to the database. The transaction record can then be cancelled, and the system that provided the transaction record can be notified of the failure. Summary of the Invention

[0005] Database transaction records received for delivering data to the database can be associated with one or more validation tasks. When one of the validation tasks fails, the failure is detected and processing of the transaction record is aborted. Instead of terminating the transaction record and requesting the system to re-initiate the process, the system can use a mapping table to determine if automatic resubmission is possible. A new transaction record can be generated by copying the call context from the original transaction record, and a portion of the transaction payload can be copied to a new transaction record that ensures the new transaction record will pass the validation task changes. The new transaction record can then be committed through the same interface that received the original transaction record, and the original transaction record can be removed from the transaction data repository.

[0006] When a transaction record is initially received for delivery to the database, it can be associated with validations that may be required before delivery. An event can be triggered to initiate the processing of the transaction record. Furthermore, transaction objects can be written to a transaction data repository that includes the transaction, its invocation context, and other descriptive material. The invocation context may include metadata describing the origin of the transaction record, such as: username, user ID, source application interface, identifier of the user who committed, modified, edited, or otherwise interacted with the transaction record, commit date / time, etc. The transaction data repository can also maintain the runtime state of the transaction record as the system processes it.

[0007] When an event triggers the processing of a transaction record, a composite can be identified for the transaction record, and a composite instance can be generated for that record. The composite instance acts as a blueprint, assembling and executing tasks for each validation of the transaction record. Validation tasks can include user authorization and validation rules for the transaction data. When a validation task fails, the system can store any failure details in the transaction data repository and send a notification of the failure to the monitor processing that communicates with the transaction console. The management account can monitor any failed tasks through the console application. Instead of simply terminating the task and notifying the user that processing must be restarted from scratch, the management account can initiate a recommit process transparent to the end user.

[0008] A mapping table can be used to determine whether a set of criteria allows for the recommittance of a new transaction. The mapping table can use the current state of transaction records in the processing pipeline, such as event state, complex state, task state, etc. If these criteria are met, a new transaction object can be generated, and the initial invocation context can be copied from the transaction data repository. Values ​​in the transaction payload can also be copied and / or modified so that the transaction record will subsequently pass the validation task. By copying the invocation context, the transaction can be committed through the original interface, allowing the system to notify the original user upon completion. Attached Figure Description

[0009] A further understanding of the nature and advantages of the various embodiments can be achieved by referring to the remainder of this specification and the accompanying drawings, wherein similar reference numerals are used throughout the drawings to refer to similar components. In some cases, sublabels are associated with reference numerals to indicate one of a plurality of similar components. When reference is made to reference numerals without specifying existing sublabels, it is intended to refer to all such plurality of similar components.

[0010] Figure 1 The diagram illustrates a system diagram of an architecture for receiving, verifying, and / or delivering transaction records to a database, according to some embodiments.

[0011] Figure 2The illustration shows a user interface that can be generated by a transaction console application according to some embodiments.

[0012] Figure 3 The diagram illustrates a system diagram of an architecture that facilitates the resubmission of faulty transaction records according to some embodiments.

[0013] Figure 4 The illustration shows a user interface for a transaction console application during resubmission processing, according to some embodiments.

[0014] Figure 5 The illustration shows a flowchart of a method for resubmitting failed database transaction records according to some embodiments.

[0015] Figure 6 The diagram illustrates a flowchart of a method for recommitting failed transaction records according to some embodiments.

[0016] Figure 7 The diagram illustrates a mapping table, according to some embodiments, that can be used to determine recommit criteria for each processing stage of a transaction record.

[0017] Figure 8 A simplified block diagram of a distributed system used to implement some of the embodiments is shown.

[0018] Figure 9 The diagram illustrates a simplified block diagram of the components of the system environment, through which the services provided can be offered as cloud services.

[0019] Figure 10 An exemplary computer system in which various embodiments can be implemented is illustrated. Detailed Implementation

[0020] This document describes an embodiment for resubmitting faulty database transaction records. Database transaction records received for delivering data to the database can be associated with one or more verification tasks. When one of the verification tasks fails, the fault is detected and processing of the transaction record is aborted. Instead of terminating the transaction record and requesting the commit system to re-initiate the process, the system can use a mapping table to determine if automatic resubmission is possible. A new transaction record can be generated by copying the call context from the original transaction record, and a portion of the transaction payload can be copied to the new transaction record with changes that ensure the new transaction record will pass the verification task. The new transaction record can then be committed through the same interface that received the original transaction record, and the original transaction record can be removed from the transaction data repository.

[0021] Many operating environments, including cloud-based environments, are built on complex layers within the software technology stack. Transaction records submitted by end users through application interfaces often fail or fail. Such failures can occur at many different stages of processing for a variety of reasons. However, regardless of the reason, when a failure occurs in a transaction submitted through a user application, the end user who submitted those transaction records is usually informed that the transaction record has failed. Following this notification, the end user's only option is to manually rebuild the transaction and manually resubmit the transaction record through the user interface. The original transaction is typically canceled, and a new transaction is required to deliver the transaction data to the database.

[0022] Transaction record failures, or "failure events," can include any situation where a transaction fails to proceed toward delivery on the database. Situations that can cause transaction record failures can be broadly categorized into at least two types. First, failures can be caused by system errors. System errors can include any hardware and / or software problems with the receiving system that prevent it from executing otherwise valid transactions. For example, a system error could include a server that is temporarily unavailable or unreachable. In another example, a system error could include writing to a database that is currently undergoing upgrades or is offline. In yet another example, a system error could include a network outage or lack of bandwidth in a communication system. In each of these cases, the problem with the receiving system's hardware / software can be the failure itself, rather than the transaction.

[0023] When encountering system errors, applications that commit transaction records can use a series of retry intervals to execute transactions. For example, system failures can be automatically recovered by periodically recommitting transactions. In some cases, various backoff algorithms can be used, where the retry interval gradually increases with each recommit (e.g., retries after 5 minutes, 15 minutes, 30 minutes, 60 minutes, etc.). As retries are committed, the hardware and / or software errors that initially caused the failure are likely to be corrected between retry intervals, allowing the transaction to eventually succeed.

[0024] In contrast to system errors, the second type of failure can be due to validation failures. Some transactions may be subject to one or more "validations" or "validation rules." If any validation fails, the transaction is rejected, preventing data from being delivered to the database. These validations can be performed on the transaction's payload to verify that the transaction complies with a set of rules before data is delivered to the database. For example, for a data category generally referred to as "business data," validations may include one or more business rules that are verified by the Business Process Manager (BPM) as part of an automated business process. Validation rules and / or algorithms can be written in Business Process Execution Language (BPEL) and executed by the BPM on the transaction's payload. For example, a transaction record requesting leave may be received from a user through a time management application. The validation rules associated with such a request may include a rule comparing the number of available leave days assigned to that user with the number of leave days requested. Another rule may include comparing the requested date with the set of days required to be attended. Leave can only be approved and the request delivered to the database used for employee records if these validation rules are met.

[0025] Note that the use of BPM with the BPEL validation algorithm is provided by way of example only and is not intended to be limiting. The embodiments described below are designed to be compatible with any set of validations on transaction records to be delivered to any type of database. For example, a database management system (DBMS) may include any type of data validation rules before delivering transactions to the database. However, the examples described below use a specific type of system architecture as an example. Such an architecture may include transaction records received from cloud-based applications, which are submitted to a service-oriented architecture (SOA) that performs BPM to validate the transaction records.

[0026] The embodiments described below provide and manage a console application that allows navigation of pending transactions based on their state. This, in turn, allows the identification and correction of erroneous transaction records generated due to validation errors by an administrative account. The algorithm described below allows the administrative account to generate a new transaction based on the faulty transaction by reusing a saved call context. This allows the new transaction to be committed and validated without any action from the initial user who committed the transaction. After the initial transaction is committed, the user can then be notified when the transaction is validated and successfully delivered to the database. The process of recommitting a second transaction based on the initial transaction is completely transparent to the end user.

[0027] Figure 1The diagram illustrates a system diagram of an architecture 100 for receiving, verifying, and / or delivering transaction records to a database, according to some embodiments. Architecture 100 may include an application interface 102. Application interface 102 may include any application accessible to a user with a user account registered with the rest of the system. Application interface 102 may be generated as a user interface on a client device communicating with a cloud environment. For example, cloud-based enterprise applications may be accessed through the client device, and any type of operation may be performed for the organization (e.g., human capital management (HCM) software, APIs, cloud-based data storage, etc.).

[0028] Application interface 102 can be configured to receive transaction records submitted by a user using a corresponding user account. The user account may include a username, user identifier (userID), and / or other identifying information, permissions, and data associated with the user. When a user account generates a transaction record, the record may be associated with a "call context." The call context may include any metadata describing the transaction record itself. For example, the call context may include the username; user ID; a reference to the user who updates, creates, submits, and / or otherwise affects the transaction record; the submission / creation date and time; the authorization number; the originating application identifier; and so on. In some cases, the call context information can be automatically extracted from the user account and / or user profile.

[0029] The application context can be packaged together with the payload of the transaction record. The payload of the transaction record can include information required for the request to deliver data to the database. This can include data values, request type, database identifier, and / or other information that the system may need to validate and / or deliver the transaction record. The payload of the transaction record can be generated by a user interface that allows users to fill in a web form or otherwise provide data values ​​and select a specific request type to submit. Application interface 102 can package the transaction record together with the calling context and provide a submission for validation.

[0030] The architecture may also include a transaction initiation process 104, which receives transaction records and initiates processes to verify the transaction records and ultimately deliver the transaction data to the database. The transaction initiation process 104 may generate events that can be submitted to various SOA systems 108 to initiate and execute verification processes. The collection of these SOA systems 108 and transaction initiation processes 104 may be individually or collectively referred to as processes(s) for performing one or more verifications associated with the received transaction records. Events triggered by the transaction initiation process 104 may include any type of event, such as Event Delivery Network (EDN) events passed to the SOA systems 108.

[0031] Transaction initiation processing 104 can also register transactions with transaction data repository 106. Transaction objects can be created and stored in transaction data repository 106, such that the transaction objects include information related to the transaction received from application interface 102. Transaction objects can include any or all information received as part of a transaction record, including the invocation context. Transaction objects can also include additional fields, such as runtime state and / or any fault information, as described in more detail below. Transaction data repository 106 can be updated by various processes in architecture 100 throughout the lifecycle of a transaction record. For example, the runtime state of transaction objects can be updated in real time, fault details can be written to transaction objects, and transactions can be validated using fields from the transaction payload.

[0032] Events received by SOA system 108 can enable SOA system 108 to generate all the processing necessary to validate transactions. For example, some embodiments may analyze the transaction type and identify SOA complexes already defined for that transaction type. An SOA complex is a combination of services, service components, and / or references deployed together to validate transactions. Essentially, an SOA complex can be thought of as a "blueprint" of one or more processes that should be executed to validate transactions. Once the correct SOA complex has been identified, an SOA complex instance can be generated to define the various processes that may be needed to validate transaction records.

[0033] SOA approval system 110 can operate based on a composite instance and begin executing various processes on BPM 112. Each process executed by BPM 112 can execute one or more validation rules to validate a transaction. Some embodiments may require explicit approval from another user to validate a transaction. For example, some transactions may require approval from a manager or administrative department. Processes executed by BPM 112 can generate tasks that are sent to various users. These tasks can manage the presentation of transaction records to users for approval and, in response, receive any approval / rejection from users.

[0034] Once the user has responded to the approval request, a determination can be made regarding whether the transaction has been validated for each validation rule. Condition 114 can be evaluated for the result of each validation process. If each result is validated, then condition 114 can return an affirmative indication to SOA approval system 110. SOA approval system 110 can then send a validation completion indication to transaction initiation process 104. This process 104 can then send a "delivery" indication to transaction data repository 106. This allows the state of the transaction objects in transaction data repository 106 to be updated to "completed". This indication can also allow the data in the transaction payload to be delivered to the database (not shown).

[0035] Alternatively, condition 114 may determine that one or more transaction records in the BPEL process performed by BPM 112 cannot be verified. For example, the user who provided approval for the transaction may have vetoed it. In another example, the data in the transaction payload may have exceeded the limit enforced by one of the verification rules. If the transaction data cannot be verified, some embodiments may request BPM 112 to attempt to verify the transaction record one or more additional times. Ultimately, if the transaction record cannot be verified, condition 114 generates an error or failure.

[0036] Some embodiments may include an SOA fault handler 116, which executes a fault handling strategy when a fault is generated by SOA processing 108. The SOA approval system 110 may provide fault details to the fault handler 116 as part of, for example, a thrown fault exception. Fault details may include specific validation rules that cannot be satisfied and / or any other information describing the failure of a transaction record or validation rule. The fault handler may execute a fault policy based on the type of fault generated.

[0037] Fault details can be passed to the transaction data repository 106 and stored along with the transaction object of this transaction record. This allows the transaction data repository 106 to maintain a real-time description of the transaction record as it is processed. The transaction object can then be updated using any fault details. Receiving fault details can also update the state of the transaction object in the transaction data repository 106 to have a "faulted" or "failed" status.

[0038] Some embodiments may provide a transaction console application 118. The transaction console application 118 may be configured to generate a graphical user interface (GUI) that provides a way to navigate all active transactions in the system. For example, the transaction data repository 106 may provide transaction objects to the transaction console application 118 so that they can be viewed and / or edited by a user. Some embodiments may also provide runtime state to the transaction console application 118 for transaction objects in the transaction data repository 106. In some cases, the state of transaction objects in the transaction data repository 106 may be updated only in response to certain events, such as initial registration, delivery commands, and / or the receipt of fault details. Other runtime states may be available and may be more descriptive. In addition to transaction objects, state may be provided so that the transaction console application 118 displays an accurate snapshot of the transaction records at the current stage of their lifecycle.

[0039] Figure 2The illustration shows a user interface 200 that can be generated by a transaction console application 118 according to some embodiments. The user interface 200 can retrieve transaction objects from the transaction data repository 106 and display summary information from a list of currently active transactions in the system. For each transaction object, the user interface 200 can retrieve information such as the transaction name 204, the transaction status 206, the name 208 of the currently executing process for verifying the transaction, the date information 210 of the transaction commit, the user account 212 of the user who committed the transaction, and / or any other information stored in the transaction object in the transaction data repository 106. Each of these transactions can be displayed in a navigable list of transactions, such as... Figure 2 As shown in the diagram. The user can select any available transaction and execute additional actions 214 that are currently available for that transaction. The available operations may depend on the status and / or type of the selected transaction record.

[0040] Various filters can be applied to the listed transaction records. In this example, filter 202 has been executed using the transaction record's status attributes. Various available attribute values ​​can be displayed below the status attributes of filter 202. These status attributes can indicate the possible status of the transaction record, such as completed, draft, failed, in progress, committed, etc. In this example, the "failed" value has been selected for filter 202. This causes only transaction records with a current status of "failed" to be displayed in the transaction record list on the right-hand side of user interface 200.

[0041] The transaction console application 118 can use the user interface 200 to provide an administrative account with a way to quickly assess the status of any transaction in the system. This allows the administrative account to quickly identify any failed transaction records and then take remedial action. Prior to this disclosure, transaction records with a status of "failed" due to validation rule failures would be canceled by the administrative account. An instruction would then be sent to the user account, instructing the user to rebuild the transaction request from scratch in a manner that would prevent further validation errors from being triggered. This resulted in a time-consuming and error-prone process that required some users to repeat the work. It also strained computer resources. Whenever a request failed, the additional network traffic used to transmit instructions to the user account and application interface 102 inevitably reduced the bandwidth available in the system for new requests. Therefore, the embodiments described herein allow the administrative account to automatically resubmit failed transaction records that were generated during the validation process without the involvement of the aforementioned user account or application interface 102.

[0042] Figure 3 The diagram illustrates a system diagram of an architecture 300 that facilitates the recommittance of faulty transaction records according to some embodiments. This architecture 300 is similar to the one described above. Figure 1The architecture 100 shown is modified, but several additional utilities are added to facilitate the generation and resubmission of faulty database transaction records by management accounts. Recall that faults typically occur when BPM 112 executes task workflows. This is often caused by failed validation rules or human users refusing authorization; for simplicity, both can be categorized as "validation." When an error occurs, the SOA fault handler 116 can receive an indication of the fault, along with fault details describing why the fault occurred, the data values ​​associated with the fault, the failed validation rules, and / or any other descriptive information about the fault. These fault details can be passed to the transaction data repository 106 and stored there as part of the transaction object record.

[0043] In this architecture 300, a monitor processing 304 can be added to communicate with the transaction console application 118. In addition to the transaction data repository 106, fault details from the SOA fault handler 116 can be sent to the monitor processing 304. This allows the monitor processing 304 to receive real-time updates on any faults occurring in the system. The transaction console 118 can provide summary information for any pending transactions, and the monitor processing 304 can immediately display any fault details associated with the displayed transactions on the console. As mentioned above, the transaction console application 118 can allow management accounts to filter pending transactions based on their status. This can be used to identify any transaction records currently in a fault condition.

[0044] Prior to this disclosure, a faulty transaction record would cause the management account to clear the transaction record from the transaction data repository 106. This would also generate an instruction sent to the end user, notifying them of the failure. At this point, the end user would be required to restart and resubmit a new transaction record that would pass the validation that failed in the previous attempt.

[0045] This architecture 300 allows the system to recover and recommit transaction records without requiring any input from user accounts. Recommit processing 302 can be provided through the transaction console application 118, enabling administrative accounts to recreate, edit, and recommit faulty transaction records. When a faulty transaction record is selected in the transaction console application 118, one of the available actions can include a recommit action, which automatically executes multiple algorithms in the background to populate and commit a new transaction record.

[0046] After initiating a recommit action, multiple recommit tasks 306 can be executed to generate and commit transaction records. First, task 306 may include an algorithm that reads the call context of the original faulty transaction record from transaction data repository 106. Recall that the call context from transaction data repository 106 may include information associated with the initial generation and commit of the transaction record using application interface 102 with a user account. Therefore, the call context may include information describing the original end user, a reference to application interface 102, the date and time the original transaction record was committed, and so on. If the management account attempts to recreate the faulty transaction record using conventional methods, the new transaction committed to transaction initiation processing 104 will necessarily include a new call context referencing the management account, the current date and time, and some other application interface. This call context will then cause the system to send a completion message to the management account, and it can remove the transaction from the visibility of the original end user. Instead of requiring changes to transaction initiation processing 104 or other elements of architecture 300, recommit task 306 can copy at least a portion of the call context from the original transaction record in transaction data repository 106. This allows the system to perceive the new transaction record being generated as if it were the original transaction record created by application interface 102.

[0047] In some embodiments, resubmitting task 306 may allow the copying of the calling context to be configurable by the management account. For example, some types of tasks may be generated such that the creation / commit time is changed to the current time when the new transaction record is generated. In some cases, the calling context may be required to reference a management account rather than an end user. Each of these different cases depends on the specific type of task and / or the requirements of the specific application. Therefore, the management account can customize how fields are copied from the original calling context and replaced with fields representing the current calling context.

[0048] Resubmitting task 306 may also include a task that generates a new transaction. Note that the transaction submitted from the original application interface 102 to the transaction initiation handler 104 may be referred to herein as a "transaction," while the corresponding object stored in the transaction data repository 106 may be referred to as a "transaction object." This is done simply to distinguish the transaction received by the transaction initiation handler 102 from the transaction subsequently stored in the transaction data repository 106. However, it should be understood that the application interface 102 packages information describing the transaction into an object passed to the transaction initiation handler. Information from that object can then be stored in the transaction data repository 106 as part of another object. The transaction object in the transaction data repository 106 may include any / all fields from the object received in the transaction initiation handler 104, as well as other information such as status, fault details, currently being executed processing, call context, etc.

[0049] The new transaction generated by resubmitting task 306 can generate a new object that includes at least a portion of the original calling context as described above. The new transaction can also include any / all fields from the original transaction stored in the transaction data repository 106. For example, a request to change a user's state can include both the old and new states. These states can be copied to the new transaction. In another example, a request to schedule a vacation can include dates, number of vacation days, etc., and these fields can also be copied to the new transaction. In some cases, the new transaction may appear substantially identical to the original transaction.

[0050] Some implementations allow the management account to modify the payload of the original transaction copied from the original transaction. For example, some original transactions may include invalid data fields or data fields that violate one or more validation rules, causing the original transaction to fail. The management account can take additional actions at this stage so that the new transaction passes validation when it is recommitted. For example, the management account can change one or more fields in the payload of the original transaction so that it no longer violates validation rules, such as exceeding the number of days of leave that may be required. In another example, the management account can make the fields in the new transaction the same as the original fields, but the management account can take actions outside the transaction to make the transaction record pass validation. Continuing with the leave example above, the management account can use a user account to obtain more leave days or transfer leave days from another user so that the original task can now pass the required validation. Once any changes have been made, the new transaction can be packaged as an object.

[0051] The recommit task 306 may also include a task to recommit the new transaction to the transaction initiation process 104. The new transaction can be committed through the same interface that committed the original transaction from application interface 102. This allows transaction initiation process 104 to treat new recommitted transaction records in the same way it handles any other commit from any application interface. This also allows transaction initiation process 104 and SOA 108 to process the new transaction records without changing their operational behavior. For example, transaction initiation process 104 can register the new transaction in the transactional data repository and raise a new EDN event, causing SOA 108 to generate a new composite instance to begin processing the validation of the recommitted database transaction records.

[0052] In some embodiments, the task of recommitting a new transaction can also remove the transaction object corresponding to the original transaction from the transaction data repository 106. Because the transaction initiation process 104 can receive and process new transaction records, it can provide the new transaction object to the transaction data repository 106. This allows the removal of the original transaction record to avoid duplicate objects and confusion for the end user. This prevents notifications related to faulty transactions that are being cancelled and replaced with new transaction records from being sent to the end user account. Any notifications generated for the end user account related to the new transaction can instead refer to the replication call context, and therefore appear to the end user account as a reference to the original transaction. This also allows the recommit process to be completely transparent to the end user account.

[0053] Figure 4 The illustration shows a user interface 400 for a transaction console application 118 during recommit processing, according to some embodiments. (Using data from...) Figure 3 The system architecture 300's monitor processing 304 and user interface 400 can provide a list of transactions filtered from the global transaction list due to having a "failed" status. The displayed information can include the real-time status of stages in the verification process that failed. For example, each transaction record displayed in user interface 400 that failed during the "document approval" stage might correspond to a rejection by a human approver.

[0054] When the administrator account selects one of the transaction records displayed in the user interface 400, several actions 402 can become available. First, one of the actions 402 can allow the administrator account to terminate the processing. As described above, this removes the transaction record from the transaction data repository 106 and from the user interface 400. In some cases, this also sends a notification to the end-user account informing them that the processing of this transaction record has been terminated. This allows the end-user to restart and commit a new transaction record.

[0055] Another action in action 402 may include a recovery action. By selecting a recovery action, the management account can initiate the aforementioned recommit task 306. For example, selecting a recovery action could copy at least a portion of the original call context, import one or more fields from the original transaction payload, generate a new transaction object, and commit the new transaction object to the transaction initiation process 104. This can also remove the original transaction from the user interface 400 when the corresponding transaction object is removed from the transaction data repository 106. If the filtering criteria used to display transaction records are changed in the user interface 400, the new transaction will subsequently appear as a transaction without a "failed" status.

[0056] Figure 5A flowchart 500 illustrating a method for resubmitting failed database transaction records according to some embodiments is illustrated. The method may include receiving a first transaction (502) to be delivered to the database. The first transaction may be received from the application interface as described above and may include any type of transaction that updates, adds, and / or removes data from the database. The first transaction may be accompanied by one or more validations to be completed before delivery to the database. For example, validation may include satisfying validation rules, receiving automatic and / or manual approval, and / or any other type of requirement.

[0057] The method may further include writing transaction objects to a transaction data repository (504). The transaction data repository may receive transaction objects for each transaction received by the system. The transaction object may include the payload of the original transaction and metadata describing the transaction. In some embodiments, the transaction object may store a call context, including a reference to the end user who created the transaction record, the application on which the transaction was generated, the date / time the transaction record was created, committed, modified, or otherwise received interaction, etc. The transaction object may later store additional information, including runtime state, fault details, executed processing, passed validation, etc., as the system processes the transaction record.

[0058] The method may also include submitting the first transaction to a process (506) for performing one or more validations. This process may include multiple sub-processes, such as a transaction initiation process that passivates the transaction, stores the transaction object in a transaction data repository, and raises events (such as EDN events) to initiate transaction processing. This may also include processes that are part of SOA, such as SOA approval systems and BPM. Processes in SOA can identify complexes, generate complex instances to govern how transactions are processed, and execute BPEL tasks in a BPM workflow to perform validation tasks. These various processes are described above. Figure 1 and Figure 3 Detailed explanation is provided.

[0059] The method may further include determining that at least one validation for the first transaction has failed (508). This failure may include failing to validate one or more validation rules within the transaction record. The failure may also include rejection by the user account responsible for providing manual approval for the transaction record. This failure may be captured by an SOA failure handler, which aggregates failure details describing various characteristics of the failure. Some embodiments may store the failure details in a transaction data repository and / or report the failure details to a monitor in a transaction console application, as described above. Figure 3 As described in [the text].

[0060] The method may also include retrieving a transaction object (510) from a transaction data repository. This transaction object may be associated with the original transaction and may be retrieved when a recommit action is selected from the transaction console application. Retrieving the original transaction object may be part of a plurality of algorithms based on the above regarding Figure 3 and Figure 4 The described failed task is used to initiate a new task and resubmit it.

[0061] The method may further include copying the calling context from the transaction object to a second transaction (512). The second transaction may be a new transaction created to replace the original transaction. Any / all original calling contexts may be copied from the original transaction object to the new transaction so that the new transaction appears to the system as if it originated from the same user, the same time, and the same location as the original transaction. In some embodiments, the system may also copy any / all transaction payloads from the original transaction object to the new transaction. The management account may modify data fields in the second transaction. The management account may alternatively or additionally make changes or perform processing outside the transaction such that the original transaction payload will pass validation.

[0062] The method may also include submitting a second transaction to a process for performing one or more validations (514). The submission of the second transaction can be received through an interface that is the same as or similar to the interface that received the original first transaction from the application interface. Submitting the second transaction can trigger an EDN event again, generate a composite instance, initiate a set of tasks executed by BPM, etc. This resubmission can be done without involving additional input from the end-user account.

[0063] It should be recognized that, Figure 5 The specific steps shown provide a specific method for resubmitting erroneous database transaction records according to various embodiments of the present invention. According to alternative embodiments, other sequences of steps may also be performed. For example, alternative embodiments of the present invention may perform the above steps in a different order. Furthermore, Figure 5 The various steps shown may include multiple sub-steps that can be performed in various orders as appropriate, depending on the individual steps. Furthermore, additional steps may be added or removed depending on the specific application. Many variations, modifications, and substitutions will be recognized by those skilled in the art.

[0064] Figure 6A flowchart 600 illustrating a method for recommitting a failed transaction record according to some embodiments is shown. Flowchart 600 describes additional steps that may be taken during the recommit process of steps 510-514 in flowchart 500 above. The method may include receiving a selection (602) for the failed transaction record. This selection may be received via a transaction console and may be accompanied by a selection of an action indicating that the failed transaction should be recovered. In some embodiments, the selection may include multiple transactions to be recovered through the same process.

[0065] The method may also include accessing a mapping table to determine whether the selected transaction is eligible to be recommitted (604). The ability to recommit a transaction record may depend on the current stage at which the transaction record has been processed from commit to completion. At each processing stage, certain criteria may need to be met if the transaction record is to be recommitted using the above processing.

[0066] Figure 7 The diagram illustrates a mapping table 700 according to some embodiments, which can be used to determine recommit criteria for each processing stage of a transaction record. When a failure occurs, the process can identify the runtime state of the transaction record. This process can be listed in the first column of the mapping table 700 and can be used as a key to look up other values ​​in the table. Available states for a transaction record can include draft, committed, in progress, automatic recovery, manual recovery, error, and completed. Each of these transaction states can also include the state of the EDN event that initiated the validation process, the state of the SOA composite instance, and the state of one or more BPM tasks. For example, for a committed transaction, and in the case where an EDN event has been raised and a composite instance has been initiated, recommitting may be allowed if one of the event, composite instance, and / or BPM task has not yet been created. In another example, if the transaction state is in an error state, the transaction can be terminated and recommitted as described above.

[0067] Return to Figure 6 If the current state of a transaction determines, based on the mapping table, that the transaction record does not meet the conditions for recommitting (606), then the state of the transaction record can be changed to "Terminated," indicating that the state has been terminated. The end user may then need to manually recommit the transaction as described above.

[0068] Alternatively, if it is determined that the transaction record is eligible for recommittance, a second transaction can be initiated as described above (608). This may include cleaning up or clearing the state of the transaction objects of the previous transaction in the transaction data repository, as well as the corresponding SOA composite instance. This may also include querying EDN event details and the corresponding transaction payload from the transaction data repository. This step may also include creating a new EDN invocation context and setting the user mode to the user who originally committed the first transaction. The transaction initiation process can be invoked again to raise a new EDN event indicating that a new transaction has been committed, and a new composite instance and BPEL process can be initiated. As described above, these processes can perform the corresponding validations or each of the new transaction records (610), and the SOA system can generate an indication that all validations were successful (612). The transaction record dimension can then be delivered to the database and the status can be changed to "Terminated" (614).

[0069] It should be recognized that, Figure 6 The specific steps shown provide a particular method for resubmitting faulty database transaction records according to various embodiments. According to alternative embodiments, other sequences of steps may also be performed. For example, alternative embodiments of the invention may perform the steps outlined above in a different order. Furthermore, Figure 6 The steps shown may include multiple sub-steps, which may be performed in various orders suitable for the individual steps. Furthermore, depending on the specific application, additional steps may be added or removed. Many variations, modifications, and substitutions will be recognized by those skilled in the art.

[0070] Each method described herein can be implemented by a computer system. Each step of these methods can be performed automatically by the computer system and / or can be provided with input / output involving a user. For example, a user can provide input for each step in the method, and each of these inputs can provide a specific output in response to a request for such input, wherein the output is generated by the computer system. Each input can be received in response to a corresponding requested output. Furthermore, input can be received from a user, received as a data stream from another computer system, retrieved from a memory location, retrieved via a network, requested from a web service, etc. Similarly, output can be provided to a user, provided as a data stream to another computer system, stored in memory, sent via a network, provided to a web service, etc. In short, each step of the methods described herein can be performed by a computer system and can involve any number of inputs, outputs, and / or requests that may or may not involve a user with respect to the computer system. Those steps that do not involve a user can be said to be performed automatically by the computer system without human intervention. Therefore, it will be understood from this disclosure that each step of each method described herein can be modified to include inputs and outputs going to and from a user, or can be performed automatically by the computer system without human intervention, wherein any determination is made by the processor. Furthermore, some embodiments of each method described herein can be implemented as instruction sets stored on tangible, non-transitory storage media to form tangible software products.

[0071] Figure 8 A simplified diagram is depicted for implementing a distributed system 800 of one embodiment. In the illustrated embodiment, the distributed system 800 includes one or more client computing devices 802, 804, 806, and 808 configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., OracleForms), etc., via one or more networks 810. A server 812 may be communicatively coupled to remote client computing devices 802, 804, 806, and 808 via network 810.

[0072] In various embodiments, server 812 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided as web-based services or cloud services or under a Software as a Service (SaaS) model to users of client computing devices 802, 804, 806, and / or 808. Users operating client computing devices 802, 804, 806, and / or 808 may then use one or more client applications to interact with server 812 to utilize the services provided by these components.

[0073] In the configuration depicted in the figures, software components 818, 820, and 822 of system 800 are shown as being implemented on server 812. In other embodiments, one or more components of system 800 and / or the services provided by these components may also be implemented by one or more of client computing devices 802, 804, 806, and / or 808. A user operating the client computing device can then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be recognized that various different system configurations are possible and may differ from the distributed system 800. The embodiments shown in the figures are therefore an example of a distributed system for implementing the system of the embodiments and are not intended to be limiting.

[0074] Client computing devices 802, 804, 806, and / or 808 can be portable handheld devices (e.g., Cellular phone Computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google) Head-mounted displays (or similar devices) that run Microsoft Windows And / or software for various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, etc.), and with internet access, email, and SMS services enabled. Or other communication protocols. The client computing device can be a general-purpose personal computer, for example, including those running various versions of Microsoft... Personal computers and / or laptops. Client computing devices can be running a variety of commercially available operating systems. Workstation computers operating systems such as UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, such as, for example, Google Chrome OS). Alternatively or additionally, client computing devices 802, 804, 806, and 808 can be any other electronic device capable of communicating via one or more networks 810, such as thin client computers, internet-enabled gaming systems (e.g., with or without...). The Microsoft Xbox game console with gesture input devices and / or personal messaging devices.

[0075] Although an exemplary distributed system 800 with four client computing devices is shown, any number of client computing devices can be supported. Other devices (such as devices with sensors, etc.) can interact with the server 812.

[0076] The network(s) 810 in the distributed system 800 can be any type of network familiar to those skilled in the art, capable of supporting data communication using any of a variety of commercially available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, etc. By way of example only, the network(s) 810 can be a local area network (LAN), such as a LAN based on Ethernet, Token Ring, etc. The network(s) 810 can be a wide area network and the Internet. It can include virtual networks, including but not limited to Virtual Private Networks (VPNs), intranets, extranets, Public Switched Telephone Networks (PSTN), infrared networks, wireless networks (e.g., according to the IEEE 802.8 protocol suite), (and / or any other wireless protocol operating on any network); and / or any combination of these networks and / or other networks.

[0077] Server 812 can consist of one or more general-purpose computers, dedicated server computers (as an example, including PC (personal computer) servers), Servers can be configured as servers, mid-range servers, mainframe computers, rack-mounted servers, server farms, server clusters, or any other suitable arrangement and / or combination. In various embodiments, server 812 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 812 may correspond to a server used to perform the processes described above according to embodiments of this disclosure.

[0078] Server 812 can run any of the operating systems discussed above, as well as any commercially available server operating system. Server 812 can also run any of a variety of additional server applications and / or middleware applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, etc. Servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM, etc.

[0079] In some implementations, server 812 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of client computing devices 802, 804, 806, and 808. As an example, data feeds and / or event updates may include, but are not limited to, those provided in the original text. feed, The server 812 may receive real-time updates from one or more third-party information sources and continuous data streams. These real-time updates may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and the like. The server 812 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 802, 804, 806, and 808.

[0080] The distributed system 800 may also include one or more databases 814 and 816. Databases 814 and 816 may reside in various locations. As an example, one or more of databases 814 and 816 may reside on non-transitory storage media local to server 812 (and / or within server 812). Alternatively, databases 814 and 816 may be located remotely from server 812 and communicate with server 812 via a network-based connection or a dedicated connection. In one set of examples, databases 814 and 816 may reside in a storage area network (SAN). Similarly, any necessary files for performing the functions of server 812 may be appropriately stored locally on server 812 and / or remotely. In one set of embodiments, databases 814 and 816 may include relational databases suitable for storing, updating, and retrieving data in response to commands in SQL format, such as databases provided by Oracle.

[0081] Figure 9 This is a simplified block diagram of one or more components of a system environment 900 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system can be offered as cloud services. In the illustrated embodiment, system environment 900 includes one or more client computing devices 904, 906, and 908 that can be used by a user to interact with a cloud infrastructure system 902 providing cloud services. The client computing devices can be configured to operate client applications, such as web browsers, proprietary client applications (e.g., Oracle Forms), or some other application, which can be used by the user of the client computing devices to interact with the cloud infrastructure system 902 to use the services provided by the cloud infrastructure system 902.

[0082] It should be recognized that the cloud infrastructure system 902 depicted in the figures may have other components different from those depicted. Furthermore, the embodiment shown in the figures is merely one example of a cloud infrastructure system that can be incorporated into embodiments of the present invention. In some other embodiments, the cloud infrastructure system 902 may have more or fewer components than shown in the figures, may combine two or more components, or may have different configurations or arrangements of components.

[0083] Client computing devices 904, 906, and 908 can be devices similar to those described above for 802, 804, 806, and 808.

[0084] While the exemplary system environment 900 is shown with three client computing devices, any number of client computing devices can be supported. Other devices, such as devices with sensors, can interact with the cloud infrastructure system 902.

[0085] One or more networks 910 can facilitate the communication and exchange of data between clients 904, 906, and 908 and cloud infrastructure system 902. Each network can be any type of network familiar to those skilled in the art that supports data communication using any of a variety of commercially available protocols, including those described above for one or more networks 810.

[0086] The cloud infrastructure system 902 may include one or more computers and / or servers, which may include those computers and / or servers described above for server 812.

[0087] In some embodiments, services provided by a cloud infrastructure system may include a variety of services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. Services provided by a cloud infrastructure system can be dynamically scaled to meet the needs of users of the cloud infrastructure system. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, any service available to users from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that constitute the cloud service provider's system differ from the customer's own on-premises servers and systems. For example, a cloud service provider's system may host applications, and users may subscribe to and use these applications on demand via a communication network such as the Internet.

[0088] In some examples, services within a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided to users by the cloud provider, or as otherwise known in the art. For example, services may include password-protected access to remote storage devices in the cloud via the Internet. As another example, services may include web-based hosted relational databases and scripting language middleware engines for private use by networked developers. As yet another example, services may include access to email software applications hosted on a cloud provider's website.

[0089] In some embodiments, cloud infrastructure system 902 may include a suite of application, middleware, and database service providers delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle public cloud provided by this assignee.

[0090] In various embodiments, cloud infrastructure system 902 can be adapted to automatically provision, manage, and track customer subscriptions to services provided by cloud infrastructure system 902. Cloud infrastructure system 902 can provide cloud services via different deployment models. For example, services can be provided based on a public cloud model, where cloud infrastructure system 902 is owned by an organization selling cloud services (e.g., owned by Oracle), and the services are available to the general public or businesses in different industries. As another example, services can be provided based on a private cloud model, where cloud infrastructure system 902 operates only for a single organization and can provide services to one or more entities within that organization. Cloud services can also be provided based on a community cloud model, where cloud infrastructure system 902 and the services provided by cloud infrastructure system 902 are shared by several organizations in the relevant community. Cloud services can also be provided based on a hybrid cloud model, which is a combination of two or more different models.

[0091] In some embodiments, the services provided by the cloud infrastructure system 902 may include one or more services offered under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or other service categories that include hybrid services. A customer may subscribe to one or more services provided by the cloud infrastructure system 902 via a subscription order. The cloud infrastructure system 902 then performs processing to deliver the services in the customer's subscription order.

[0092] In some embodiments, the services provided by the cloud infrastructure system 902 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, the SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers can leverage applications running on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services providing solutions for sales performance management, enterprise integration, and business agility for large organizations.

[0093] In some embodiments, platform services may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform can be configured to provide cloud services that fall into the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared, public architecture and to leverage the shared services provided by the platform to build new applications. The PaaS platform can manage and control the underlying software and infrastructure used to provide PaaS services. Customers can access PaaS services provided by the cloud infrastructure system without having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0094] By leveraging services provided by a PaaS platform, customers can employ programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware Service), and Java cloud services. In one embodiment, the database cloud service may support a shared services deployment model that enables organizations to aggregate database resources and deliver Database as a Service to customers in the form of a database cloud. The middleware cloud service can provide customers with a platform for developing and deploying various business applications, and the Java cloud service can provide customers with a platform for deploying Java applications within the cloud infrastructure system.

[0095] Various infrastructure services can be provided by IaaS platforms within cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage devices, networks, and other basic computing resources) for customers to utilize services provided by SaaS and PaaS platforms.

[0096] In some embodiments, the cloud infrastructure system 902 may further include infrastructure resources 930 for providing resources to customers of the cloud infrastructure system for delivering various services. In one embodiment, infrastructure resources 930 may include a combination of pre-integrated and optimized hardware (such as servers, storage devices, and networking resources) to perform services provided by PaaS platforms and SaaS platforms.

[0097] In some embodiments, resources in cloud infrastructure system 902 can be shared by multiple users and dynamically reallocated as needed. Furthermore, resources can be allocated to users in different time zones. For example, cloud infrastructure system 930 can enable a first group of users in a first time zone to utilize the resources of the cloud infrastructure system for a specified number of hours, and then enable the same resources to be reallocated to another group of users located in a different time zone, thereby maximizing resource utilization.

[0098] In some embodiments, multiple internal shared services 932 may be provided, shared by different components or modules of the cloud infrastructure system 902 and by services provided by the cloud infrastructure system 902. These internal shared services may include, but are not limited to: security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, cloud-enabled services, email services, notification services, file transfer services, etc.

[0099] In some embodiments, cloud infrastructure system 902 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, cloud management functionality may include the ability to provision, manage, and track customer subscriptions received by cloud infrastructure system 902.

[0100] In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules, such as an order management module 920, an order orchestration module 922, an order supply module 924, an order management and monitoring module 926, and an identity management module 928. These modules may include or be provided using one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0101] In exemplary operation 934, a customer using a client device (such as client device 904, 906, or 908) can interact with cloud infrastructure system 902 by requesting one or more services provided by cloud infrastructure system 902 and placing an order to subscribe to one or more services offered by cloud infrastructure system 902. In some examples, the customer can access cloud user interface (UI), cloud UI 912, cloud UI 914, and / or cloud UI 916 and place subscription orders through these UIs. Order information received by cloud infrastructure system 902 in response to a customer placing an order may include information identifying the customer and the one or more services offered by cloud infrastructure system 902 that the customer wishes to subscribe to.

[0102] After a customer places an order, the order information is received via the cloud UI, 912, 914 and / or 916.

[0103] At operation 936, the order is stored in order database 918. Order database 918 can be one of several databases operated by cloud infrastructure system 918 and operating in conjunction with other system components.

[0104] At operation 938, the order information is forwarded to the order management module 920. In some cases, the order management module 920 can be configured to perform order-related billing and accounting functions, such as verifying the order and, after verification, reserving the order.

[0105] At operation 940, order information is transmitted to order orchestration module 922. Order orchestration module 922 can use the order information to orchestrate services and supply resources for customer orders. In some cases, order orchestration module 922 can use the services of order supply module 924 to orchestrate resource supply to support subscribed services.

[0106] In some embodiments, the order orchestration module 922 enables the management of business processes associated with each order and applies business logic to determine whether an order should be provisioned. At operation 942, upon receiving a new subscription order, the order orchestration module 922 sends a request to the order provisioning module 924 to allocate resources and configure those resources required to fulfill the subscription order. The order provisioning module 924 enables the allocation of resources for services subscribed by customers. The order provisioning module 924 provides an abstraction layer between the cloud services provided by the cloud infrastructure system 900 and the physical implementation layer for provisioning the resources used to provide the requested services. Therefore, the order orchestration module 922 can be isolated from implementation details such as whether services and resources are actually provisioned on demand or pre-provisioned and allocated / assigned only upon request.

[0107] At operation 944, once services and resources are supplied, notifications of the services provided can be sent to customers on client devices 904, 906, and / or 908 via the order supply module 924 of the cloud infrastructure system 902.

[0108] At operation 946, the order management and monitoring module 926 can manage and track customer subscription orders. In some cases, the order management and monitoring module 926 can be configured to collect service usage statistics from subscription orders, such as storage usage, data transfer volume, number of users, system uptime, and system downtime.

[0109] In some embodiments, the cloud infrastructure system 900 may include an identity management module 928. The identity management module 928 may be configured to provide identity services, such as access management and authorization services within the cloud infrastructure system 900. In some embodiments, the identity management module 928 may control information about customers who wish to utilize the services provided by the cloud infrastructure system 902. Such information may include information authenticating the identities of these customers and information describing what actions these customers are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 928 may also include management of descriptive information about each customer and how and by whom this descriptive information is accessed and modified.

[0110] Figure 10 An exemplary computer system 1000, in which various embodiments can be implemented, is illustrated. System 1000 can be used to implement any of the computer systems described above. As shown, computer system 1000 includes a processing unit 1004 that communicates with a plurality of peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing acceleration unit 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. Storage subsystem 1018 includes a tangible computer-readable storage medium 1022 and system memory 1010.

[0111] Bus subsystem 1002 provides a mechanism for enabling various components and subsystems of computer system 1000 to communicate with each other as intended. While bus subsystem 1002 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1002 can be any of several types of bus architectures, including memory buses or memory controllers, peripheral buses, and local buses using any architecture across various bus architectures. For example, such architectures may include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses, which may be implemented as Mezzanine buses manufactured according to the IEEE P1086.1 standard.

[0112] A processing unit 1004, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 1000. One or more processors may be included in the processing unit 1004. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, each including a single-core or multi-core processor. In other embodiments, the processing unit 1004 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0113] In various embodiments, processing unit 1004 can execute various programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in processor(s) 1004 and / or storage subsystem 1018. With appropriate programming, processor(s) 1004 can provide the various functions described above. Computer system 1000 may additionally include processing acceleration unit 1006, which may include digital signal processor (DSP), dedicated processor, etc.

[0114] The I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as those from Microsoft... A motion sensor that enables users to control devices such as Microsoft products using a natural user interface with gestures and voice commands. The 360 ​​game controller's input device interacts with the input device. The user interface input device may also include eye gesture recognition devices, such as detecting eye activity from the user (e.g., "blinking" when taking a photo and / or making menu selections) and translating the eye gesture into the input device (e.g., Google). Google input in ) Blink detector. Additionally, the user interface input device may include enabling the user to interact with a voice recognition system (e.g., ...) via voice commands. Voice recognition sensing devices for interaction with navigators.

[0115] User interface input devices may also include, but are not limited to: 3D mice, joysticks or pointing sticks, game panels and drawing tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positron emission tomography (PET), and medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0116] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices. Display subsystems may be cathode ray tubes (CRTs), flat panel devices such as those using liquid crystal displays (LCDs) or plasma displays, projection devices, touchscreens, etc. Generally, the term "output device" is used to encompass all possible types of devices and mechanisms for outputting information from computer system 1000 to a user or other computers. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0117] Computer system 1000 may include a storage subsystem 1018 containing software elements, shown as currently located within system memory 1010. System memory 1010 may store loadable and executable program instructions on processing unit 1004, as well as data generated during the execution of these programs.

[0118] Depending on the configuration and type of the computer system 1000, the system memory 1010 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that can be immediately accessed by the processing unit 1004 and / or are currently being operated and executed by the processing unit 1004. In some embodiments, the system memory 1010 may include various different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, such as during startup, a basic input / output system (BIOS) containing basic routines that facilitate the transfer of information between elements within the computer system 1000 may typically be stored in ROM. By way of example, but not limitation, the system memory 1010 also includes application 1012, program data 1014, and operating system 1016, which may include client applications, web browsers, middleware applications, relational database management systems (RDBMS), etc. As an example, operating system 1016 may include various versions of Microsoft... Apple and / or Linux operating system, and various commercially available... Or a UNIX-like operating system (including but not limited to various GNU / Linux operating systems, Google...) OS, etc.) and / or such as iOS, Phone OS 10OS and A mobile operating system based on the OS operating system.

[0119] The storage subsystem 1018 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above-described functionality when executed by a processor may be stored in the storage subsystem 1018. These software modules or instructions may be executed by the processing unit 1004. The storage subsystem 1018 may also provide a storage library for storing data used according to the present invention.

[0120] The storage subsystem 1000 may also include a computer-readable storage medium reader 1020 that can be further connected to the computer-readable storage medium 1022. Together with and optionally in conjunction with the system memory 1010, the computer-readable storage medium 1022 can generally represent a remote, local, fixed, and / or removable storage device plus storage medium for temporarily and / or more persistently containing, storing, transmitting, and retrieving computer-readable information.

[0121] The computer-readable storage medium 1022 containing code or a portion thereof may also include any suitable medium known or used in the art, including storage and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassette, magnetic tape, disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media such as data signals, data transmissions, or any other medium that can be used to transmit desired information and can be accessed by the computing system 1000.

[0122] As an example, computer-readable storage medium 1022 may include a hard disk drive that reads from or writes to a non-removable non-volatile magnetic medium, a disk drive that reads from or writes to a removable non-volatile disk, and a disk drive that reads from or writes to a removable non-volatile disk, such as a CD-ROM, DVD, and [other media]. An optical disc drive that reads from or writes to a removable, non-volatile optical disc (such as a Blu-ray disc or other optical media). Computer-readable storage medium 1022 may include, but is not limited to: Disk drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVDs, digital audio tapes, etc. Computer-readable storage media 1022 may also include: solid-state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, etc.), volatile memory-based SSDs (such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs), and hybrid SSDs using a combination of DRAM-based and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1000.

[0123] The communication subsystem 1024 provides an interface to other computer systems and networks. The communication subsystem 1024 serves as an interface for receiving data from other systems and sending data from computer system 1000 to other systems. For example, the communication subsystem 1024 enables computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1024 may include a radio frequency (RF) transceiver component (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components for accessing wireless voice and / or data networks. In some embodiments, as an addition to or alternative to the wireless interface, the communication subsystem 1024 may provide a wired network connection (e.g., Ethernet).

[0124] In some embodiments, the communication subsystem 1024 may also represent one or more users who can use the computer system 1000 to receive input communications in the form of structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc.

[0125] As an example, the communication subsystem 1024 can be configured to receive data feeds 1026 from users of social networks and / or other communication services in real time, such as... feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0126] Furthermore, the communication subsystem 1024 can also be configured to receive data in the form of a continuous data stream, which may include an event stream 1028 and / or event updates 1030 that are essentially continuous or unbounded real-time events without a clearly defined termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial price reporting systems, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, etc.

[0127] The communication subsystem 1024 can also be configured to output structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc. to one or more databases, which can communicate with one or more streaming data source computers coupled to the computer system 1000.

[0128] Computer system 1000 can be one of various types, including handheld portable devices (e.g., Cellular phone Computing tablets, PDAs), and wearable devices (e.g., Google). Head-mounted displays, PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems.

[0129] Due to the ever-evolving nature of computers and networks, the description of the computer system 1000 depicted in the figures is intended only as a concrete example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may be used and / or specific elements may be implemented in hardware, firmware, software (including applets), or combinations thereof. Additionally, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods for implementing the various embodiments.

[0130] In the foregoing description, numerous specific details have been set forth for purposes of explanation in order to provide a thorough understanding of various embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[0131] The foregoing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with enabling descriptions for implementing the exemplary embodiments. It should be understood that various changes can be made to the function and arrangement of the elements without departing from the spirit and scope of the invention as set forth in the appended claims.

[0132] Specific details have been set forth in the foregoing description to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that the embodiments can be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may have been shown as components in block diagram form so as not to obscure the embodiments with unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail to avoid obscuring the embodiments.

[0133] Furthermore, it should be noted that the various embodiments may have been described as processes depicted as flowcharts, flow diagrams, data flow diagrams, structural diagrams, or block diagrams. Although flowcharts may have described operations as sequential processes, many operations may be executed in parallel or concurrently. Additionally, the order of operations can be rearranged. A process terminates upon completion of its operation, but may have additional steps not included in the diagram. Processes may correspond to methods, functions, procedures, subroutines, subroutines, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or the main function.

[0134] The term "computer-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying one or more instructions and / or data. A code segment or machine-executable instruction can represent any combination of processing, function, subroutine, program, routine, subroutine, module, software package, class, or instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., can be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0135] Furthermore, embodiments can be implemented using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments that perform the necessary tasks can be stored in a machine-readable medium. One or more processors can perform the necessary tasks.

[0136] In the foregoing description, various aspects of the invention have been described with reference to specific embodiments thereof; however, those skilled in the art will recognize that the invention is not limited thereto. The various features and aspects of the invention described above can be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications other than those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0137] Furthermore, for illustrative purposes, the methods are described in a specific order. It should be recognized that, in alternative examples, the methods may be executed in a different order than described. It should also be recognized that the methods described above can be executed by hardware components or can be implemented as a sequence of machine-executable instructions that can be used to cause a machine (such as a general-purpose or special-purpose processor or logic circuit programmed with instructions) to execute the methods. These machine-executable instructions can be stored on one or more machine-readable media, such as CD-ROMs or other types of optical discs, floppy disks, ROM, RAM, EPROM, EEPROM, magnetic cards or optical cards, flash memory, or other types of machine-readable media suitable for storing electronic instructions. Alternatively, the methods can be executed by a combination of hardware and software.

Claims

1. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations, the operations including: Receive the first transaction to be delivered to the database, wherein the first transaction requires one or more validations before being delivered to the database; Write a transaction object to a transaction data repository, wherein the transaction object includes the invocation context of a first transaction, and the invocation context includes metadata describing the origin of the first transaction; Submit the first transaction to the process that performs the one or more verifications; Determine that at least one of the one or more verifications for the first transaction has failed; Retrieve the transaction object from the transaction data repository; Copy the invocation context from the transaction object to the second transaction; as well as The second transaction is submitted to the process that performs the one or more verifications.

2. The non-transitory computer-readable medium of claim 1, wherein the invocation context of the first transaction includes the user context of the user account that submitted the first transaction.

3. The non-transitory computer-readable medium of claim 2, wherein the user context includes a username, a user identifier, and a creation time.

4. The non-transitory computer-readable medium of claim 2, wherein the second transaction is submitted by an administrative account, different from the user account, to a process for performing the one or more verifications.

5. The non-transitory computer-readable medium of claim 1, wherein the operation further includes copying the transaction payload from the transaction object to a second transaction.

6. The non-transitory computer-readable medium of claim 1, wherein submitting the second transaction to the process for performing the one or more verifications comprises: The event that generates the notification to the Service-Oriented Architecture (SOA) system enables the SOA to perform one or more business processing execution languages ​​(BPEL) to execute the one or more verifications.

7. The non-transitory computer-readable medium of claim 6, wherein the operation further comprises: When the one or more BPEL processes determine that at least one of the one or more verifications for the first transaction has failed, an indication is sent to the SOA fault handler.

8. The non-transitory computer-readable medium of claim 7, wherein the operation further comprises: The SOA fault handler writes an indication of one or more validation failures for the first transaction to the transaction object in the transaction data repository.

9. The non-transitory computer-readable medium of claim 1, wherein the operation further comprises: Determine that each of the one or more verifications for the second transaction is successful; as well as This allows the second transaction to be delivered to the database.

10. The non-transitory computer-readable medium of claim 1, wherein the operation further comprises: Write the second transaction object of the second transaction to the transaction data repository.

11. The non-transitory computer-readable medium of claim 1, wherein the operation further comprises, after determining that at least one of the one or more verifications for the first transaction has failed: Determine the runtime state of the first transaction; and Determining the runtime state of the first transaction allows the second transaction to be committed.

12. The non-transitory computer-readable medium of claim 11, wherein the runtime state of the first transaction indicates that the first transaction is in progress and the SOA complex instance or BPEL task is in an error state.

13. The non-transitory computer-readable medium of claim 11, wherein the runtime state of the first transaction indicates that the first transaction has been committed and notifies the SOA system that an event has been generated, but the SOA complex instance or BPEL task has not yet been created.

14. The non-transitory computer-readable medium of claim 11, wherein determining the runtime state of the first transaction to allow the submission of the second transaction comprises: Access a data table that includes a list of transaction states with corresponding transaction requirements to commit a new transaction based on an existing transaction.

15. The non-transitory computer-readable medium of claim 1, wherein the operation further comprises terminating the first transaction and clearing the transaction object from the transaction data repository.

16. The non-transitory computer-readable medium of claim 1, wherein determining that at least one of the one or more verifications for the first transaction has failed comprises: Monitor the transaction objects in the transaction data repository and the indications of one or more verification failures for the first transaction generated by the SOA fault handler.

17. The non-transitory computer-readable medium of claim 1, wherein determining that at least one of the one or more verifications for the first transaction has failed comprises: Generate a transaction console application that provides a list of transactions to be delivered to the database; The application receives the selection for the first transaction through the transaction console; as well as Display the runtime status of the first transaction in the transaction console application.

18. The non-transitory computer-readable medium of claim 1, wherein the one or more verifications include receiving authorization from the user to deliver the first transaction to the database.

19. A system comprising: One or more processors; as well as A memory device including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: Receive the first transaction to be delivered to the database, wherein the first transaction requires one or more validations before being delivered to the database; Write a transaction object to a transaction data repository, wherein the transaction object includes the invocation context of a first transaction, and the invocation context includes metadata describing the origin of the first transaction; Submit the first transaction to the process that performs the one or more verifications; Determine that at least one of the one or more verifications for the first transaction has failed; Retrieve the transaction object from the transaction data repository; Copy the invocation context from the transaction object to the second transaction; as well as The second transaction is submitted to the process that performs the one or more verifications.

20. A method for recommitting faulty database transaction records, the method comprising: Receive the first transaction to be delivered to the database, wherein the first transaction requires one or more validations before being delivered to the database; Write a transaction object to a transaction data repository, wherein the transaction object includes the invocation context of a first transaction, and the invocation context includes metadata describing the origin of the first transaction; Submit the first transaction to the process that performs the one or more verifications; Determine that at least one of the one or more verifications for the first transaction has failed; Retrieve the transaction object from the transaction data repository; Copy the invocation context from the transaction object to the second transaction; as well as The second transaction is submitted to the process that performs the one or more verifications.

Images