Handling failed database transaction records

Abstract

A database transaction record received to commit data to a database may be associated with one or more validation tasks. If one of the validation tasks fails, a failure is detected and processing of the transaction record is stopped. Instead of terminating the transaction record and requesting the submitting system to restart the process, the system may use a mapping table to determine whether automatic resubmission is possible. A new transaction record that copies the invocation context from the original transaction record may be generated, and portions of the transaction payload may be copied to the new transaction record with changes that ensure the new transaction record passes the validation tasks. The new transaction record can then be submitted through the same interface that the original transaction record was received through, and the original transaction record can be removed from the transaction data store.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. patent application Ser. No. 16 / 780,862, filed Feb. 3, 2020, and entitled “HANDLING FAULTED DATABASE TRANSACTION RECORDS.”

[0002] background A database transaction represents a process performed on a database within a database management system. A transaction is typically represented by a transaction record that represents aspects of a request to make one or more changes to a database, including values ​​to be changed, tables to be accessed, and other descriptive information. Within a database management system, a transaction record may generate multiple operations that are performed on multiple tables within the database management system. However, the transaction as a whole may be represented by a transaction record as one atomic, consistent, isolated, and durable process.

[0003] To prevent unauthorized or incorrect transaction records from being committed to the database, some transaction records may include one or more validations that may be performed on the transaction record before the database commit is allowed. These validations may include receiving authorization from additional systems / users and validation rules that are run on the values ​​in the transaction record. If the transaction record fails the validation procedures, the database management system prevents the transaction record from being committed to the database. The transaction record may then be canceled and the system providing the transaction record may be notified of the failure. Summary of the Invention

[0004] overview A database transaction record received to commit data to a database may be associated with one or more validation tasks. If one of the validation tasks fails, a failure is detected and processing of the transaction record is stopped. Instead of terminating the transaction record and asking the submitting system to restart the process, the system may use a mapping table to determine whether automatic resubmission is possible. A new transaction record that copies the invocation context from the original transaction record may be generated, and portions of the transaction payload may be copied to the new transaction record with changes that ensure that the new transaction record passes the validation tasks. The new transaction record may then be submitted through the same interface through which the original transaction record was received, and the original transaction record may be removed from the transaction data store.

[0005] When a transaction record is initially received for committing to the database, it may be associated with any validation that may be required before it is committed to the database. An event may occur that initiates the processing of the transaction record. In addition, a transaction object may be written to a transaction data store that contains the transaction, an invocation context for the transaction, and other descriptive material. The invocation context may include metadata describing the origin of the transaction record, such as the user name, user ID, source application interface, an identifier for the user submitting, modifying, editing, or otherwise interacting with the transaction record, submission date / time, etc. The transaction data store may also maintain the run-time status of the transaction record as it is processed by the system.

[0006] When an event occurs to initiate processing of a transaction record, a composite may be identified for the transaction record and a composite instance may be created for the record. The composite instance acts as a blueprint for assembling and executing tasks for each of the validations for the transaction record. The validation tasks may include user authorization and validation rules for the transaction data. If a validation task fails, the system may store any failure details in a transaction data store and send a notification of the failure to a monitoring process that communicates with the transaction console. An administration account may monitor any failed tasks through a console application. Instead of simply terminating the task and notifying the user that the process must be restarted from scratch, the administration account may initiate a resubmission process that is transparent to the end user.

[0007] A mapping table may be used to determine if a set of criteria are met to allow resubmission of a new transaction. The mapping table may use the current status of the transaction record in the processing pipeline, such as event status, composite status, task status, etc. If these criteria are met, a new transaction object may be created and the original invocation context may be copied from the transaction data store. Values ​​in the transaction payload may also be copied and / or modified so that the transaction record subsequently passes validation tasks. By copying the invocation context, the transaction may be submitted through the original interface such that the system still notifies the original user when the process is complete.

[0008] BRIEF DESCRIPTION OF THE DRAWINGS A further understanding of the nature and advantages of the present invention may be realized with reference to the remaining portions of the specification and the drawings. The same reference numerals are used throughout the several drawings to refer to similar components. In some cases, a sub-label is associated with a reference numeral to indicate one of multiple similar components. When a reference numeral is made without specification to an existing sub-label, it is intended to refer to all such multiple similar components. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a system diagram of an architecture for receiving, validating, and / or committing transaction records to a database, according to some embodiments. [Diagram 2] FIG. 2 illustrates a user interface that may be generated by a transaction console application according to some embodiments. [Diagram 3] FIG. 1 is a system diagram of an architecture that facilitates resubmission of failed transaction records, according to some embodiments. [Figure 4] FIG. 13 illustrates a user interface for a Transaction Console Application during a resubmission process, according to some embodiments. [Diagram 5] FIG. 2 illustrates a flowchart of a method for resubmitting a failed database transaction record, according to some embodiments. [Figure 6] FIG. 2 illustrates a flowchart of a method for performing resubmission of a failed transaction record, according to some embodiments. [Figure 7] FIG. 2 illustrates a mapping table that may be used to determine resubmission criteria for each processing stage of a transaction record, according to some embodiments. [Figure 8] FIG. 1 is a simplified block diagram of a distributed system for implementing some of the embodiments. [Figure 9] FIG. 1 is a simplified block diagram of components of a system environment in which services provided by components of an embodiment system may be provided as cloud services. [Figure 10] FIG. 1 illustrates an example computer system upon which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Detailed Description Described herein are embodiments for resubmitting a failed database transaction record. A database transaction record received to commit data to a database may be associated with one or more validation tasks. If one of the validation tasks fails, a failure is detected and processing of the transaction record is stopped. Instead of terminating the transaction record and asking the submitting system to restart the process, the system may use a mapping table to determine whether automatic resubmission is possible. A new transaction record is generated that copies the invocation context from the original transaction record, and portions of the transaction payload may be copied to the new transaction record with changes that ensure that the new transaction record passes the validation tasks. The new transaction record can then be submitted through the same interface through which the original transaction record was received, and the original transaction record can be removed from the transaction data store.

[0011] Many operating environments, including cloud-based environments, are built on multiple layers in a software technology stack. Transaction records submitted by end users through application interfaces often result in failures or failures. Such failures can occur at various stages of the process for many different reasons. Regardless of the reason, however, when failures occur in transactions submitted through user applications, the end users who submitted those transaction records are often notified that the transaction records failed. After this notification, the only option for the end users is to manually reconstruct the transaction and manually resubmit the transaction record through the user interface. To commit the transaction data to the database, the original transaction is typically canceled and a new transaction is required.

[0012] A transaction record failure or "failure incident" may include any situation in which a transaction is not progressing towards being committed on a database. Situations that may cause a transaction record failure may be roughly subdivided into at least two categories. First, the failure may be caused by a system error. A system error may include any hardware and / or software problem with the receiving system that prevents the receiving system from executing a transaction that would otherwise be valid. For example, a system error may include a server that is temporarily unavailable or unreachable. In another example, a system error may include writing to a database that is currently being upgraded or is offline. In another example, a system error may include a network failure or lack of bandwidth in a communication system. In each of these situations, a problem with the hardware / software of the receiving system may be the cause of the failure, rather than the transaction itself.

[0013] If a system error is encountered, the application submitting the transaction record may use a series of retry intervals to execute the transaction. For example, a system failure may be automatically recovered by periodically resubmitting the transaction. In some cases, various back-off algorithms may be used in which the retry interval is gradually increased with each resubmission (e.g., retrying after 5 minutes, 15 minutes, 30 minutes, 60 minutes, etc.). When a retry is submitted, the hardware and / or software error that initially caused the failure will be corrected between the retry intervals so that the transaction eventually succeeds.

[0014] In contrast to system errors, a second category of failures may be due to validation failures. Some transactions may be subject to one or more "validations" or "validation rules." If any of the validations fail, the transaction may be rejected so that the data is not committed to the database. These validations may be performed on the payload of the transaction to ensure that the transaction adheres to a set of rules before committing the data to the database. For example, for a class of data generally referred to as "business data," the validation may include one or more business rules that are verified by a Business Process Manager (BPM) as part of an automated business process. The validation rules and / or algorithms may be written in Business Process Execution Language (BPEL) and executed by the BPM on the payload of the transaction. For example, a transaction record requesting time off may be received from a user through a time management application. A validation rule associated with such a request may include a rule that compares the number of available vacation days allocated to that user with the number of vacation days being requested. Another rule may include a comparison of the requested date with a set of days that need to be attended. Only if these validation rules are met can the time off be approved and the request committed to the database for employee records.

[0015] It should be noted that the use of BPM with BPEL validation algorithms is provided merely as an example and is not intended to be limiting. The embodiments described below are designed to accommodate any set of validations for transaction records to be committed to any type of database. For example, a Database Management System (DBMS) may include any type of data validation rules before a transaction is committed to a database. However, the example described below uses a specific type of system architecture as an example. This architecture may include transaction records received from a cloud-based application that are submitted to a Service Oriented Architecture (SOA) that runs BPM to validate the transaction records.

[0016] The embodiments described below provide and manage a console application that allows pending transactions to be navigated based on their status. This then allows transaction records that generated failures due to validation errors to be identified and corrected through the management account. The algorithm described below allows the management account to generate a new transaction based on the failed transaction by reusing the saved invocation context. This allows the new transaction to be submitted and validated without requiring action from the original user that submitted the transaction. After submitting the first transaction, the user can then be notified when the transaction is validated and successfully committed to the database. The process of resubmitting a second transaction based on the first transaction can be completely transparent to the end user.

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

[0018] The application interface 102 may be configured to receive transaction records submitted by users using corresponding user accounts. The user accounts may include a username, a user identifier (user ID), and / or other identifying information, permissions, and data associated with the user. When a user account creates a transaction record, the record may be associated with a "call context." The call context may include any metadata that describes the transaction record itself. For example, the call context may include the user's name, user ID, references to users who updated, created, submitted, and / or otherwise interacted with the transaction record, submission / creation date and time, authorization number, originating application identifier, etc. In some cases, information about the call context may be automatically extracted from the user account and / or user profile.

[0019] The application context may be packaged in the payload of a transaction record. The payload of a transaction record may include information necessary for a request to commit data to a database. This may include data values, request type, database identifiers, and / or other information that may be required by the system to validate and / or commit the transaction record. The payload of a transaction record may be generated by a user interface that allows a user to fill in a web form or otherwise provide data values ​​and select a particular request type to be submitted. The application interface 102 may package the transaction record with the invocation context and provide the submission for validation.

[0020] The architecture may also include a transaction initiation process 104 that receives the transaction records and initiates a process for validating the transaction records and ultimately committing the transaction data to a database. The transaction initiation process 104 may generate events that may be submitted to various SOA systems 108 to initiate and perform validation processes. The collection of these SOA systems 108 and the transaction initiation process 104 may be individually or collectively referred to as a process for performing one or more validations associated with the received transaction records. The events raised by the transaction initiation process 104 may include any type of event, such as an Event Delivery Network (EDN) event that is passed to the SOA systems 108.

[0021] The transaction initiation process 104 may also register the transaction in the transaction data store 106. A transaction object may be created and stored in the transaction data store 106 such that the transaction object contains information related to the transaction received from the application interface 102. The transaction object may contain any or all of the information received as part of the transaction record, including the invocation context. The transaction object may also contain additional fields, such as runtime status and / or any failure information, as described in more detail below. The transaction data store 106 may be updated by various processes in the architecture 100 throughout the lifecycle of the transaction record. For example, the runtime status of the transaction object may be updated in real time, failure details may be written to the transaction object, and fields from the transaction payload may be used to validate the transaction.

[0022] The event received by the SOA system 108 may cause the SOA system 108 to generate all of the processes necessary to validate the transaction. For example, some embodiments may analyze a transaction type and identify an SOA composite defined for that transaction type. An SOA composite is an assembly of services, service components, and / or references that are deployed together to validate a transaction. In essence, an SOA composite may be thought of as a "blueprint" for one or more processes to be executed to validate a transaction. Once an appropriate SOA composite is identified, an SOA composite instance may be created to define the various processes that may be needed to validate a transaction record.

[0023] The SOA approval system 110 may act on the composite instance and initiate the execution of various processes for the BPM 112. Each of the processes executed by the BPM 112 may execute one or more validation rules to validate the transaction. Some embodiments may require explicit approval by another user to validate the transaction. For example, some transactions may require manager or administrative approval. The processes executed by the BPM 112 may generate tasks that are sent to various users. These tasks may manage the presentation of transaction records to the users for approval and the corresponding approval / rejection from the users.

[0024] Once the user responds to the approval request, a determination can be made for each of the validation rules as to whether the transaction is validated. For the outcome of each validation process, a conditional 114 can be evaluated. If each of the outcomes is validated, the conditional 114 can return a positive indication to the SOA authorization system 110. The SOA authorization system 110 can then send an indication that the validation is complete to the transaction initiation process 104. This process 104 can then send an indication of "commit" to the transaction data store 106. This can cause the status of the transaction object in the transaction data store 106 to be updated such that its status is updated to "completed". This indication can also cause the data in the transaction payload to be committed to a database (not shown).

[0025] Alternatively, conditional 114 may determine that one or more of the BPEL processes executed by BPM 112 will not be able to validate the transaction record. For example, a user providing approval for the transaction may have rejected the transaction. In another example, data in the transaction payload may have exceeded a limit enforced by one of the validation rules. If the transaction data cannot be validated, some embodiments may request that BPM 112 attempt to validate the transaction record one or more more times. Finally, if the transaction record cannot be validated, conditional 114 may generate an error or a fault.

[0026] Some embodiments may include a SOA fault handler 116 that executes fault handling policies when a fault is generated by the SOA process 108. The SOA authorization system 110 may provide fault details to the fault handler 116, for example as part of a thrown fault exception. The fault details may include the specific validation rule that could not be satisfied and / or other information that describes the transaction record or describes the failure of the validation rule. The fault handler may execute fault policies based on the type of fault that is generated. The fault details may be passed to the transaction data store 106 and stored with the transaction object for this transaction record. This allows the transaction data store 106 to maintain a real-time description of the transaction record as it is processed. Any fault details may then be used to update the transaction object. Receiving the fault details may also update the status of the transaction object in the transaction data store 106 to have a status of "fault" or "failed".

[0027] 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 of the transactions that are active in the system. For example, the transaction data store 106 may provide transaction objects to the transaction console application 118 so that they may be viewed and / or edited by a user. Some embodiments may also provide runtime status to the transaction console application 118 for transaction objects in the transaction data store 106. In some cases, the status of a transaction object in the transaction data store 106 may be updated only in response to certain events, such as a new registration, a commit command, and / or receipt of failure details. Other runtime statuses may be available and may be more descriptive. Status may be provided in addition to the transaction object such that the transaction console application 118 displays an accurate snapshot of the transaction record at its current stage in its lifecycle.

[0028] FIG. 2 illustrates a user interface 200 that may be generated by the transaction console application 118, according to some embodiments. The user interface 200 may extract transaction objects from the transaction data store 106 and display summary information in a list of transactions that are currently active in the system. For each transaction object, the user interface 200 may extract information such as the name of the transaction 204, the status of the transaction 206, the name of the current process 208 that is running to validate the transaction, the date the transaction was submitted 210, the user account 212 that submitted the transaction, and / or any other information stored in the transaction object in the transaction data store 106. Each of these transactions may be displayed in a list of transactions that is navigable as shown in FIG. 2. A user may select any of the available transactions and perform additional actions 214 that may currently be available for that transaction. The actions that are available may depend on the status and / or type of the transaction record selected.

[0029] Various filters may be applied to the listed transaction records. In this example, filter 202 is implemented using the status attribute of the transaction records. Various available attribute values ​​may be displayed under the status attribute for filter 202. These status attributes may indicate possible statuses for the transaction records, such as completed, draft, failed, in progress, submitted, etc. In this example, the value "Failed" is selected for filter 202. This ensures that only transaction records that have a current status with a value of "Failed" are displayed in the transaction records list on the right side of user interface 200.

[0030] The transaction console application 118 may use the user interface 200 to provide a way for the administrative account 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 corrective action. Prior to this disclosure, a transaction record with a "failed" status due to a failed validation rule would have been canceled by the administrative account. An indication would then have been sent to the user account instructing the user to start over and rebuild the transaction request in such a way that the validation error would no longer be triggered. This resulted in a time-consuming and error-prone process that required double effort on the part of the user. This also created a strain on computer resources. Whenever a request failed, the additional network traffic used to send the indication to the user account and the application interface 102 would have necessarily reduced the bandwidth available for new requests in the system. Thus, the embodiments described herein allow the administrative account to automatically resubmit failed transaction records that generated failures during the validation process without requiring the involvement of the user account or the application interface 102 described above.

[0031] FIG. 3 illustrates a system diagram of an architecture 300 that facilitates resubmission of failed transaction records, according to some embodiments. This architecture 300 is similar to the architecture 100 illustrated in FIG. 1 above, but with the addition of several additional utilities to facilitate the creation and resubmission of failed database transaction records by an administrative account. Recall that faults will generally occur when a task workflow is executed by the BPM 112. This is often caused by a failure of a validation rule or a denial of authorization from a human user, both of which may be categorized as "validation" for simplicity. When an error occurs, the SOA fault handler 116 may receive not only an indication of the fault, but also fault details describing why the fault occurred, data values ​​associated with the fault, the failed validation rule, and / or other descriptive information about the fault. These fault details may be passed to the transaction data store 106 and stored therein as part of the transaction object record.

[0032] In this architecture 300, a monitor process 304 may be added to communicate with the transaction console application 118. Fault details from the SOA fault handler 116 may be sent to the monitor process 304 in addition to the transaction data store 106. This allows the monitor process 304 to receive real-time updates of any faults occurring in the system. The transaction console 118 may provide summary information about any of the pending transactions, and the monitor process 304 may cause the console to immediately display any fault details associated with the displayed transaction. As mentioned above, the transaction console application 118 may allow an administrative account to filter the pending transactions according to status. This may be used to identify any of the transaction records that are currently in a fault state.

[0033] Prior to this disclosure, a failed transaction record would have resulted in the administrative account erasing the transaction record from the transaction data store 106. This would also have generated an indication sent to the end user notifying them that a failure had occurred. At this point, the end user would have been requested to try again and resubmit a new transaction record that would pass the validation that had failed in the previous attempt.

[0034] This architecture 300 allows the system to recover and resubmit a transaction record without requiring input from a user account. A resubmission process 302 may be provided through the transaction console application 118 to allow an administrative account to recreate, edit, and resubmit a failed transaction record. When a failed transaction record is selected in the transaction console application 118, one of the available actions may include a resubmit action that automatically runs multiple algorithms in the background to enter and submit a new transaction record.

[0035] After a resubmit action is initiated, multiple resubmit tasks 306 may be executed to generate and submit the transaction record. First, task 306 may include an algorithm that reads the invocation context from the transaction data store 106 for the original transaction record that failed. Recall that the invocation context from the transaction data store 106 may include information associated with the initial creation and submission of the transaction record through the application interface 102 using a user account. Thus, the invocation context may include information describing the original end user, a reference to the application interface 102, the date and time the original transaction record was submitted, and so on. If the administrative account were to attempt to recreate the failed transaction record using conventional means, the new transaction submitted to the transaction initiation process 104 would necessarily include a new invocation context that referenced the administrative account, the current date and time, and some other application interface. This invocation context would then cause the system to send a completion message to the administrative account, which could remove the transaction from the original end user's view. Instead of requiring changes to be made to the transaction initiation process 104 or other elements of the architecture 300, the resubmit task 306 may copy at least a portion of the invocation context from the original transaction record in the transaction data store 106. This allows the new transaction record being created to appear in the system as if it were the original transaction record created by the application interface 102.

[0036] In some embodiments, the resubmit task 306 may allow the copying of the invocation context to be configurable by an administrative account. For example, some types of tasks may be created such that when a new transaction record is created, the creation / submission time is changed to the current time. Some situations may require that the administrative account be referenced by the invocation context rather than the end user. Each of these different situations depends on the requirements of the particular type of task and / or the particular application. Thus, the administrative account may customize how fields are copied from the original invocation context and instead replace them with fields that would represent the current invocation context.

[0037] The resubmit task 306 may also include a task to generate a new transaction. Note that the transaction submitted from the original application interface 102 to the transaction initiation process 104 may be referred to herein as a "transaction," while the corresponding object stored in the transaction data store 106 may be referred to as a "transaction object." This is done simply to distinguish the transaction received by the transaction initiation process 102 from one that is later stored in the transaction data store 106. However, it should be understood that the application interface 102 will package information describing the transaction into an object that is passed to the transaction initiation process. Information from that object may then be stored in the transaction data store 106 as part of another object. The transaction object in the transaction data store 106 may include any / all fields from the object received at the transaction initiation process 104, along with other information such as status, failure details, the current process being executed, invocation context, etc.

[0038] The new transaction generated by the resubmit task 306 may generate a new object that includes at least a portion of the original invocation context as described above. The new transaction may also include any / all fields from the original transaction as stored in the transaction data store 106. For example, a request to change a user status may include the old status as well as the new status. These statuses may be copied to the new transaction. In another example, a request to schedule a vacation may include dates, vacation dates, etc., and these fields may also be copied to the new transaction. In some cases, the new transaction may look nearly identical to the original transaction.

[0039] Some embodiments allow the administrative account to make changes to the original transaction payload copied from the original transaction. For example, some original transactions may contain invalid data fields or data fields that break one or more validation rules, thereby causing the original failure. The administrative account may take additional measures at this stage so that the new transaction passes validation when resubmitted. For example, the administrative account may change one or more of the fields in the original transaction payload so that it no longer breaks a validation rule, e.g., exceeds the number of days that can be requested for vacation. In another example, the administrative account may leave the fields in the new transaction the same as the original fields, but the administrative account may take measures unrelated to the transaction so that the transaction record passes validation. Continuing with the vacation example above, the administrative account may cause the user account to acquire more vacation days or transfer vacation days from another user so that the original quest now passes the required validation. Once any changes have been made, the new transaction may be packaged as an object.

[0040] The resubmit task 306 may also include a task to resubmit the new transaction to the transaction initiation process 104. The new transaction may be submitted through the same interface through which the original transaction was submitted from the application interface 102. This allows the transaction initiation process 104 to treat the resubmitted new transaction record the same as it treats any other submission from any application interface. This also allows the transaction initiation process 104 and the SOA 108 to process the new transaction record without changing the way they operate. For example, the transaction initiation process 104 may register the new transaction in the transaction data store and raise a new EDN event so that the SOA 108 creates a new composite instance to begin processing validation for the resubmitted database transaction record.

[0041] In some embodiments, the task of resubmitting the new transaction may also cause the transaction object corresponding to the original transaction to be removed from the transaction data store 106. As the transaction initiation process 104 may receive and process the new transaction record, it may provide the new transaction object to the transaction data store 106. This allows the original transaction record to be removed to avoid duplicate objects and confusion for the end user. This prevents notifications from being sent to the end user account associated with the failed transaction that is being canceled and replaced with the new transaction record. Any notifications generated for the end user account associated with the new transaction may instead refer to the copied invocation context and thus appear in the end user account as referencing the original transaction. This also allows the resubmission process to be completely transparent to the end user account.

[0042] 4 shows a user interface 400 for the transaction console application 118 during the resubmission process, according to some embodiments. Using the monitoring process 304 from the architecture 300 of FIG. 3, the user interface 400 may provide a list of transactions filtered from a global list of transactions by those having a status of "Failed." The displayed information may include a real-time status of the stage in the validation process where the failure occurred. For example, each of the transaction records displayed in the user interface 400 failed during the "Document Approval" stage, which likely corresponds to a rejection by an approving person.

[0043] When the administrative account selects one of the transaction records displayed in the user interface 400, several actions 402 may be available. First, one of the actions 402 may allow the administrative account to terminate the process. As described above, this removes the transaction record from the transaction data store 106 and the user interface 400. In some cases, this may also send a notification to the end user account that the process has finished for this transaction record. This allows the end user to start over and submit a new transaction record.

[0044] Another one of the actions 402 may include a recovery action. By selecting the recovery action, the administrative account may initiate the resubmit task 306 described above. For example, selecting the recovery action may copy at least a portion of the original invocation context, import one or more of the fields from the original transaction payload, generate a new transaction object, and submit the new transaction object to the transaction initiation process 104. This may also remove the original transaction from the user interface 400 when the corresponding transaction object is removed from the transaction data store 106. If the filter criteria for displaying transaction records is changed in the user interface 400, the new transaction will then appear as a transaction that does not have a status of "failed."

[0045] 5 shows a flowchart 500 of a method for resubmitting a failed database transaction record, according to some embodiments. The method may include receiving (502) a first transaction to be committed to the database. The first transaction may be received from an application interface as described above and may include any type of transaction that updates, adds, and / or removes data in the database. The first transaction may involve one or more validations to be completed before being committed to the database. For example, the validations may include satisfying validation rules, receiving automatic and / or human approval, and / or any other type of requirement.

[0046] The method may also include writing (504) the transaction object to a transaction data store. The transaction data store may receive a transaction object for each transaction received by the system. The transaction object may include the payload of the original transaction along with metadata describing the transaction. In some embodiments, the transaction object may store an invocation context including a reference to the end user who created the transaction record, the application from which the transaction was generated, the date / time the transaction record was created, submitted, modified, or otherwise received interaction, etc. The transaction object may then store additional information as the transaction record is processed in the system, including runtime status, failure details, processes performed, validations passed, etc.

[0047] The method may additionally include a step of submitting (506) the first transaction to a process for performing one or more validations. This process may include multiple sub-processes such as a transaction initiation process that deactivates the transaction, stores the transaction object in a transaction data store, and raises an event (such as an EDN event) to start transaction processing. This may also include processes that are part of the SOA, such as an SOA approval system and BPM. Processes within the SOA may identify composites, create composite instances to define how the transaction is processed, and execute BPEL tasks in a BPM workflow to perform validation tasks. These various processes are shown in detail in Figures 1 and 3 above.

[0048] The method may further include determining (508) that at least one of the validations for the first transaction has failed. The failure may include a failure to fulfill one or more validation rules that validate data in the transaction record. The failure may also include a refusal by a user account that has the task of providing human approval for the transaction record. The failure may be caught by an SOA fault handler that aggregates fault details that describe various characteristics of the fault. Some embodiments may store the fault details in a transaction data store and / or report the fault details to a monitor in a transaction console application such as described above in FIG. 3.

[0049] The method may also include retrieving (510) a transaction object from a transaction data store. This transaction object may be associated with the original transaction and may be retrieved when a resubmit action is selected from the transaction console application. Retrieving the original transaction object may be part of multiple algorithms that initiate a resubmission of a new task based on a failed task, as described above with respect to Figures 3 and 4.

[0050] The method may additionally include a step of copying (512) the invocation context from the transaction object to a second transaction. The second transaction may be a new transaction generated to replace the original transaction. Some / all of the original invocation context may be copied from the original transaction object to the new transaction to make the new transaction appear to the system as if it originated from the same user at the same time and place as the original transaction. In some embodiments, the system may also copy some / all of the transaction payload from the original transaction object to the new transaction. The administrative account may make changes to data fields in the second transaction. The administrative account may alternatively or additionally make changes or run processes unrelated to the transaction so that the original transaction payload passes validation.

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

[0052] It should be understood that the particular steps illustrated in FIG. 5 provide a particular method of resubmitting a failed database transaction record in accordance with various embodiments of the present invention. Other orders of steps may also be performed in accordance with alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Also, individual steps illustrated in FIG. 5 may include multiple sub-steps that may be performed in various orders as appropriate for the individual step. Furthermore, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize numerous variations, modifications, and alternatives.

[0053] 6 shows a flowchart 600 of a method for performing resubmission of a failed transaction record, according to some embodiments. Flowchart 600 illustrates additional steps that may be performed during the resubmission process described above in steps 510-514 of flowchart 500. The method may include receiving (602) a selection of the failed transaction record. The selection may be received through a transaction console and may involve 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.

[0054] The method may also include accessing (604) the mapping table to determine whether the selected transaction is eligible to be resubmitted. The ability to resubmit the transaction record may depend on the current stage of the transaction record as it is processed from submission to completion. At each processing stage, certain criteria may need to be met if the transaction record is to be resubmitted using the process described above.

[0055] FIG. 7 illustrates a mapping table 700 that may be used to determine resubmission criteria for each processing stage of a transaction record, according to some embodiments. When a failure occurs, a process may identify the run-time status of the transaction record. This process may be listed in the first column of the mapping table 700 and may be used as a key to look up other values ​​in the table. Available statuses for a transaction record may include draft, submitted, in progress, auto-recovery, manual recovery, error, and completed. Each of these transaction statuses may also include the status of the SOA composite instance and the status of the BPM task, as well as the status for the EDN event that initiates the validation process. For example, if a transaction is submitted and an EDN event occurs to initiate a composite instance, resubmission may be enabled if one of the event, composite instance, and / or BPM task has not yet been created. In another example, if the transaction status is in an error state, the transaction may be terminated and resubmitted as described above.

[0056] Returning to Figure 6, if the current status of the transaction according to the mapping table determines that the transaction record is not eligible for resubmission (606), the status of the transaction record may be changed to "Terminated," indicating that the status is terminated. The end user may then need to manually resubmit the transaction as described above.

[0057] Alternatively, if the transaction record is determined to be eligible for resubmission, a second transaction may be initiated as described above (608). This may include cleaning or erasing the transaction object for the previous transaction in the transaction data store and the status of the corresponding SOA composite instance. This may also include querying the EDN event details and the corresponding transaction payload from the transaction data store. This step may also include creating a new EDN invocation context and setting the user mode to the user who originally submitted the first transaction. The transaction initiation process may be called again to raise a new EDN event indicating that a new transaction is submitted, and a new composite instance and BPEL process may be started. As described above, these processes may perform each of the corresponding validations or the new transaction record (610), and the SOA system may generate an indication that all of the validations are successful (612). The transaction record may then be committed to the database and the status may be changed to "finished" (614).

[0058] It should be understood that the particular steps illustrated in FIG. 6 provide a particular method of resubmitting a failed database transaction record according to various embodiments. Other orders of steps may be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Additionally, individual steps illustrated in FIG. 6 may include multiple sub-steps that may be performed in various orders as appropriate for the individual step. Additionally, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize numerous variations, modifications, and alternatives.

[0059] Each of the methods described herein may be implemented by a computer system. Each of the steps of these methods may be performed automatically by the computer system and / or may be provided with input / output involving a user. For example, a user may provide inputs for each step in the method, and each of these inputs may be responsive to a particular output that requests such input, and the output is generated by the computer system. Each input may be received in response to a corresponding requested output. Further, inputs may be received from a user, from another computer system, as a data stream, retrieved from a memory location, retrieved over a network, requested from a web service, etc. Similarly, outputs may be provided to a user, to another computer system, as a data stream, stored in a memory location, transmitted over a network, provided to a web service, etc. In short, each of the steps of the methods described herein may be performed by a computer system and may involve any number of inputs, outputs, and / or requests to and from the computer system that may or may not involve a user. Those steps that do not involve a user may be said to be performed automatically by the computer system without human intervention. Thus, it will be understood in light of this disclosure that each step of each method described herein may be modified to include input and output from a user, or may be performed automatically by a computer system without human intervention, in which case all decisions are made by a processor. Additionally, some embodiments of each method described herein may be implemented as a set of instructions stored on a tangible, non-transitory storage medium to form a tangible software product.

[0060] 8 shows a simplified diagram of a distributed system 800 for implementing one of the embodiments. In the illustrated embodiment, the distributed system 800 includes one or more client computing devices 802, 804, 806, and 808 that are configured to execute and operate client applications, such as web browsers, dedicated clients (e.g., Oracle Forms), etc., over 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.

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

[0062] In the illustrated configuration, the software components 818, 820, and 822 of the system 800 are shown as being implemented on the server 812. In other embodiments, one or more of the components of the system 800 and / or the services provided by these components may also be implemented by one or more of the client computing devices 802, 804, 806, and / or 808. A user operating a client computing device may 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 understood that a variety of different system configurations are possible that may differ from the distributed system 800. The illustrated embodiment is thus an example of a distributed system for implementing an embodiment system and is not intended to be limiting.

[0063] The client computing devices 802, 804, 806, and / or 808 may be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)), or wearable devices (e.g., Google Glass® head mounted display) and may run software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android®, BlackBerry® 10, Palm OS, and may be capable of Internet, email, short message service (SMS), BlackBerry®, or other communications protocols. The client computing devices may be general purpose personal computers, including by way of example personal computers and / or laptop computers running various versions of the Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing device may be a workstation computer running any of the various commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, client computing devices 802, 804, 806, and 808 may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, capable of communicating over network 810.

[0064] Although the exemplary distributed system 800 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the server 812.

[0065] Network 810 in distributed system 800 may be any type of network familiar to those skilled in the art capable of supporting data communications using any of a variety of commercially available protocols, including, but not limited to, TCP / IP (transmission control protocol / Internet protocol), SNA (systems network architecture), IPX (Internet packet exchange), Apple Talk, etc. By way of example only, network 810 may be a local area network (LAN), such as one based on Ethernet, Token-Ring, etc. Network 810 may be a wide area network and the Internet. This may include virtual networks, including without limitation a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating under any of the Institute of Electrical and Electronics (IEEE) 802.11 protocol suite, Bluetooth, and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0066] Servers 812 may be comprised of one or more general purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. In various embodiments, servers 812 may be adapted to execute one or more services or software applications described in the foregoing disclosure. For example, servers 812 may correspond to servers for performing the above-described processes according to one embodiment of the present disclosure.

[0067] Server 812 may run an operating system, including any of those mentioned above, as well as any commercially available server operating system. Server 812 may also run any of a variety of additional server applications and / or mid-tier applications, including a hypertext transport protocol (HTTP) server, a file transfer protocol (FTP) server, a common gateway interface (CGI) server, a JAVA server, a database server, etc. Exemplary database servers include, without limitation, those commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0068] In some implementations, server 812 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of client computing devices 802, 804, 806, and 808. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third party information sources and continuous data streams that 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, automobile traffic monitoring, and the like. Server 812 may also include one or more applications for displaying the data feeds and / or real-time events via one or more display devices of client computing devices 802, 804, 806, and 808.

[0069] Distributed system 800 may also include one or more databases 814 and 816. Databases 814 and 816 may reside in a variety of locations. By way of example, one or more of databases 814 and 816 may reside on a non-transitory storage medium local to (and / or within) server 812. Alternatively, databases 814 and 816 may be remote from server 812 and communicate with server 812 via a network-based or dedicated connection. In one set of embodiments, databases 814 and 816 may reside on a storage-area network (SAN). Similarly, any necessary files to perform the functions ascribed to server 812 may be stored locally on server 812 and / or remotely, as appropriate. In one set of embodiments, databases 814 and 816 may include relational databases, such as those provided by Oracle, adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0070] 9 is a simplified block diagram of one or more components of a system environment 900 that may provide services provided by one or more components of an embodiment system as cloud services, according to one embodiment of the disclosure. In the illustrated embodiment, the system environment 900 includes one or more client computing devices 904, 906, and 908 that may be used by a user to interact with a cloud infrastructure system 902 that provides cloud services. These client computing devices may be configured to run a client application, such as a web browser, a dedicated client application (e.g., Oracle Forms), or some other application, that may be used by a user of the client computing device to interact with the cloud infrastructure system 902 to use the services provided by the cloud infrastructure system 902.

[0071] It should be understood that the illustrated cloud infrastructure system 902 may have other components than those shown, and the illustrated embodiment is merely one example of a cloud infrastructure system that may incorporate an embodiment of the invention. In some other embodiments, cloud infrastructure system 902 may have more or fewer components than those shown, may combine two or more components, or may have components in a different configuration or arrangement.

[0072] The client computing devices 904 , 906 , and 908 may be devices similar to those described above for 802 , 804 , 806 , and 808 .

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

[0074] Network 910 may facilitate communication and exchange of data between clients 904, 906, and 908 and cloud infrastructure system 902. Each network may be any type of network familiar to those skilled in the art capable of supporting data communications using any of a variety of commercially available protocols, including those described above for network 810.

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

[0076] In an embodiment, the services provided by a cloud infrastructure system may include a number of services made 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, and the like. The services provided by the cloud infrastructure system may be dynamically scaled to meet the needs of its users. A particular instantiation of a service provided by the cloud infrastructure system is referred to herein as a "service instance." In general, any service made available to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own premises servers and systems. For example, the cloud service provider's system may host an application, and a user may order and use the application on demand over a communications network such as the Internet.

[0077] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided to users by a cloud vendor or otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a web-services-based hosted relational database and scripting language middleware engine for private use by networked developers. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

[0078] In one embodiment, cloud infrastructure system 902 may include a suite of application, middleware, and database service offerings that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such a cloud infrastructure system is the Oracle Public Cloud offered by the present assignee.

[0079] In various embodiments, cloud infrastructure system 902 may be adapted to automatically provision, manage, and track customer subscriptions to services offered by cloud infrastructure system 902. Cloud infrastructure system 902 may provide cloud services through different deployment models. For example, the services may be provided under a public cloud model, where cloud infrastructure system 902 is owned by an organization that sells cloud services (e.g., owned by Oracle) and the services are made available to the general public or different industry enterprises. As another example, the services may be provided under a private cloud model, where cloud infrastructure system 902 is operated only for a single organization and may provide services for one or more entities within that organization. Cloud services may also be provided under a community cloud model, where cloud infrastructure system 902 and the services offered by cloud infrastructure system 902 are shared by several organizations in an associated community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0080] In some embodiments, the services provided by cloud infrastructure system 902 may include one or more services provided under a Software as a Service (SaaS) category, a Platform as a Service (PaaS) category, an Infrastructure as a Service (IaaS) category, or other category of services including hybrid services. A customer may order one or more services provided by cloud infrastructure system 902 via a subscription order. Cloud infrastructure system 902 then processes to provide the services in the customer's subscription order.

[0081] In some embodiments, the services provided by the cloud infrastructure system 902 may include, without limitation, 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 under the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for providing the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without the need for the customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, without limitation, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0082] In some embodiments, platform services may be provided by the cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall under the PaaS category. Examples of platform services may include, without limitation, services that enable organizations (such as Oracle) to consolidate existing applications on a shared common architecture, and the ability to build new applications that leverage shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure for providing the PaaS services. Customers can obtain the PaaS services provided by the cloud infrastructure system without the customer having to purchase separate licenses and support. Examples of platform services include, without limitation, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), and the like.

[0083] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system as well as 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 services), and Java cloud services. In one embodiment, the database cloud services may support a shared service deployment model that allows organizations to pool database resources and provide database-as-a-service in the form of a database cloud to customers. The middleware cloud services may provide a platform for customers to develop and deploy various business applications, and the Java cloud services may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0084] In a cloud infrastructure system, a variety of different infrastructure services may be provided by the IaaS platform that facilitate management and control of basic computing resources, such as storage, network, and other underlying computing resources, for customers that utilize the services provided by the SaaS and PaaS platforms.

[0085] In an embodiment, cloud infrastructure system 902 may also include infrastructure resources 930 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources 930 may include a pre-integrated and optimized combination of hardware, such as servers, storage, and networking resources for running the services offered by the PaaS and SaaS platforms.

[0086] In some embodiments, resources in cloud infrastructure system 902 may be shared by multiple users and dynamically reallocated per demand. In addition, resources may be allocated to users in different time zones. For example, cloud infrastructure system 930 may allow a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a certain number of hours, and then allow reallocation of those same resources to another set of users located in a different time zone, thereby maximizing resource utilization.

[0087] In an embodiment, multiple internal shared services 932 may be provided that are shared by different components or modules of cloud infrastructure system 902 and by the services provided by cloud infrastructure system 902. These internal shared services may include, without limitation, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, etc.

[0088] In an embodiment, cloud infrastructure system 902 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functionality may include capabilities for provisioning, managing, tracking customer subscriptions received by cloud infrastructure system 902, and the like.

[0089] In one embodiment, as shown, 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 provisioning 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 configuration and / or combination.

[0090] In an example operation 934, a customer using a client device, such as client device 904, 906, or 908, may interact with cloud infrastructure system 902 by requesting one or more services offered by cloud infrastructure system 902 and placing a subscription order for one or more services offered by cloud infrastructure system 902. In an embodiment, the customer may access a cloud user interface (UI), cloud UI 912, cloud UI 914, and / or cloud UI 916, and place a subscription order via these UIs. Order information received by cloud infrastructure system 902 in response to the customer placing the order may include information identifying the customer and the one or more services offered by cloud infrastructure system 902 to which the customer intends to subscribe.

[0091] After an order is placed by a customer, order information is received via cloud UI 912, 914, and / or 916.

[0092] At operation 936, the order is stored in order database 918. Order database 918 may be one of several databases operated by cloud infrastructure system 918, along with other system elements.

[0093] At operation 938, the order information may be routed to the order management module 920. In some cases, the order management module 920 may be configured to perform billing and accounting functions related to the order, such as validating the order and booking the order after validation.

[0094] At operation 940, information regarding the order may be communicated to the order orchestration module 922. The order orchestration module 922 may utilize the order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some cases, the order orchestration module 922 may orchestrate the provisioning of resources to support the subscribed service using the services of the order provisioning module 924.

[0095] In one embodiment, the order orchestration module 922 enables management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. Upon receiving a new subscription order at operation 942, 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 the services ordered by the customer. The order provisioning module 924 provides a level of abstraction between the cloud services provided by the cloud infrastructure system 900 and the physical implementation layer used to provision resources to provide the requested services. The order orchestration module 922 may thus be decoupled from implementation details such as whether the services and resources are actually provisioned on the fly or whether they are pre-provisioned and allocated / allocated only upon request.

[0096] At operation 944 , once the services and resources have been provisioned, a notification of the provided services may be sent by the order provisioning module 924 of the cloud infrastructure system 902 to the customer on the client devices 904 , 906 , and / or 908 .

[0097] At operation 946, the customer's subscription order may be managed and tracked by the order management and monitoring module 926. In some cases, the order management and monitoring module 926 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, the amount of system uptime and system downtime.

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

[0099] 10 illustrates an exemplary computer system 1000 upon which various embodiments of the present invention may be implemented. System 1000 may 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 number of peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing accelerator 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 a system memory 1010.

[0100] Bus subsystem 1002 provides a mechanism for allowing the various components and subsystems of computer system 1000 to communicate with each other as intended. Although bus subsystem 1002 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1002 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured to the IEEE P1386.1 standard.

[0101] The processing unit 1004, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1000. The processing unit 1004 may include one or more processors. These processors may include single-core or multi-core processors. In an embodiment, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, with single or multi-core processors included in each processing unit. 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.

[0102] In various embodiments, the processing unit 1004 can execute various programs in response to program code and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in the processor 1004 and / or in the storage subsystem 1018. Through suitable programming, the processor 1004 can provide the various functionality discussed above. The computer system 1000 may additionally include a processing accelerator 1006, which may include a digital signal processor (DSP), a special purpose processor, or the like.

[0103] The I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touch pads or touch screens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors that allow a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and verbal commands. User interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that detects eye activity from a user (e.g., “blinking” during picture taking and / or menu selection) and translates the eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (eg, the Siri® navigator) through voice commands.

[0104] User interface input devices may also include, without limitation, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, etc.

[0105] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1000 to a user or to another computer. For example, user interface output devices may include, without limitation, a variety of display devices that visually convey text, graphics, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

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

[0107] Depending on the configuration and type of 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 are immediately accessible to and / or currently being operated on and executed by the processing unit 1004. In some implementations, the system memory 1010 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1000, such as during start-up, may typically be stored in a ROM. By way of example and not limitation, the system memory 1010 also illustrates application programs 1012, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like, program data 1014, and an operating system 1016. By way of example, operating system 1016 may include various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, without limitation, various GNU / Linux operating systems, Google Chrome OS, etc.), and / or mobile operating systems, such as iOS, Windows Phone, Android OS, BlackBerry 10 OS, Palm OS operating systems, etc.

[0108] The storage subsystem 1018 may also provide a tangible computer readable storage medium for storing data structures and basic programming that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above 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 repository for storing data used in accordance with the present invention.

[0109] Storage subsystem 1000 may also include a computer readable storage medium reader 1020 that may be further connected to a computer readable storage medium 1022. Along with, and optionally in combination with, the system memory 1010, computer readable storage medium 1022 may comprehensively represent remote, local, fixed and / or removable storage devices as well as storage media for containing, storing, transmitting and retrieving computer readable information on a temporary and / or more permanent basis.

[0110] The computer readable storage medium 1022 containing the code or portions of code may also include any suitable medium known or used in the art, including storage and communication media such as volatile and non-volatile, removable and non-removable media, etc., implemented in any method or technology for storing and / or transmitting information. This may include tangible computer readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage, 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 the desired information and that is accessible by the computing system 1000.

[0111] By way of example, the computer readable storage medium 1022 may include a hard disk drive that reads from and writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from and writes to removable, non-volatile magnetic media, and an optical disk drive that reads from and writes to removable, non-volatile optical disks, such as CD ROMs, DVDs, Blu-Ray® disks, or other optical media. The computer readable storage medium 1022 may include, but is not limited to, a Zip® drive, a flash memory card, a universal serial bus (USB) flash drive, a secure digital (SD) card, a DVD disk, a digital video tape, and the like. The computer-readable storage media 1022 may also include flash memory-based solid-state drives (SSDs), enterprise flash drives, SSDs based on non-volatile memory such as solid-state ROM, SSDs based on volatile memory 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 SSDs and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1000.

[0112] The communications subsystem 1024 provides an interface to other computer systems and networks. The communications subsystem 1024 serves as an interface for receiving data from and transmitting data to other systems other than the computer system 1000. For example, the communications subsystem 1024 may enable the computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1024 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technology such as 3G, 4G, or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family of standards), or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 1024 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0113] In some embodiments, the communications subsystem 1024 may also receive incoming communications in the form of structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc., for one or more users using the computer system 1000.

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

[0115] Additionally, the communications subsystem 1024 may also be configured to receive data in the form of a continuous data stream, which may be continuous or infinite in nature with no apparent end, which may include an event stream 1028 of real-time events and / or event updates 1030. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

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

[0117] The computer system 1000 may be one of a variety of types, including a handheld mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0118] Due to the ever-changing nature of computers and networks, the description of the computer system 1000 shown in the figures is intended only as a specific example. Many other configurations are possible having more or fewer components than the system shown in the figures. For example, customized hardware may also be used and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods for implementing various embodiments.

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

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

[0121] In the foregoing description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may 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 in undue detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail so as not to obscure the embodiments.

[0122] It should also be noted that the particular embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operations as a sequential process, many of the operations may occur in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to which it was called or to the main function.

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

[0124] Furthermore, the embodiments may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor may perform the necessary tasks.

[0125] In the foregoing specification, aspects of the invention have been described with respect to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. The various features and aspects of the invention described above may be used individually or together. Also, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

[0126] In addition, for purposes of illustration, the methods have been described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different from that described. It should also be understood that the methods described above may be performed by hardware components or embodied in 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 circuitry programmed with the instructions, to perform the methods. These machine-executable instructions may be stored on one or more machine-readable media, for example, CD-ROM or other types of optical disks, floppy diskettes, ROM, RAM, EPROM, EEPROM, magnetic or optical cards, flash memory, or other types of machine-readable media suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.

Claims

1. 1. A program comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations, the operations comprising: receiving a first transaction to be committed to a database, the first transaction requiring one or more validations before being committed to the database, the operations further comprising: writing a transaction object to a transaction data store, the transaction object including an invocation context for the first transaction, the invocation context including metadata, the metadata describing an origin of the first transaction and generated at least in part from a user profile of a user account that submitted the first transaction, the operations further comprising: submitting the first transaction to a process for performing the one or more validations; determining that at least one of the one or more validations for the first transaction has failed; and retrieving the transaction object from the transaction data store; copying the invocation context from the transaction object to a second transaction; and submitting the second transaction to the process for performing the one or more validations.

2. 2. The program of claim 1, wherein the invocation context for the first transaction includes a user context for the user account that submitted the first transaction.

3. The program of claim 2 , wherein the user context includes a username, a user identifier, and a creation time.

4. 3. The method of claim 2, wherein the second transaction is submitted to the process for performing the one or more validations by an administrative account that is different from the user account.

5. The method of claim 1 , wherein the operation further comprises copying a transaction payload from the transaction object to the second transaction.

6. 6. The program of claim 1, wherein submitting the second transaction to the process for performing the one or more validations comprises generating an event to notify a service-oriented architecture (SOA) system so that the SOA causes one or more business process execution language (BPEL) processes to perform the one or more validations.

7. 7. The program of claim 6, wherein the operations further comprise sending an indication to an SOA fault handler if the one or more BPEL processes determine that at least one of the one or more validations for the first transaction has failed.

8. 8. The program of claim 7, wherein the operations further comprise the SOA fault handler writing an indication to the transaction object in the transaction data store that the one or more validations for the first transaction failed.

9. The operation further comprises: determining that each of the one or more validations for the second transaction is successful; and and causing the second transaction to be committed to the database.

10. The program of claim 1 , wherein the operations further comprise: writing a second transaction object for the second transaction to the transaction data store.

11. The operations further include, after determining that at least one of the one or more validations for the first transaction has failed, determining a runtime status of the first transaction; and determining that the runtime status of the first transaction allows the second transaction to be submitted.

12. 12. The program of claim 11, wherein the runtime status of the first transaction indicates that the first transaction is in progress and an SOA composite instance or a BPEL task is in an error state.

13. 12. The program of claim 11, wherein the runtime status of the first transaction indicates that the first transaction has been submitted and an event has been generated that notifies an SOA system, but an SOA composite instance or a BPEL task has not yet been created.

14. 12. The program of claim 11, wherein determining that the runtime status of the first transaction allows the second transaction to be submitted comprises accessing a data table containing a list of transaction statuses having corresponding transaction requirements for submitting a new transaction based on an existing transaction.

15. The program of any one of claims 1 to 14, wherein the operations further comprise: terminating the first transaction and deleting the transaction object from the transaction data store.

16. 16. The program of claim 1, wherein determining that at least one of the one or more validations for the first transaction has failed comprises monitoring the transaction object in the transaction data store and an indication generated by an SOA fault handler that the one or more validations for the first transaction have failed.

17. Determining that at least one of the one or more validations for the first transaction has failed includes: generating a transaction console application that provides a list of transactions to be committed to the database; receiving a selection of the first transaction through the transaction console application; and displaying a runtime status of the first transaction in the transaction console application.

18. The program of any one of claims 1 to 17, wherein the one or more verifications include receiving authorization from a user to allow the first transaction to be committed to the database.

19. 1. A system comprising: one or more processors; one or more memory devices, the one or more memory devices containing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: receiving a first transaction to be committed to a database, the first transaction requiring one or more validations before being committed to the database, the operations further comprising: writing a transaction object to a transaction data store, the transaction object including an invocation context for the first transaction, the invocation context including metadata, the metadata describing an origin of the first transaction and generated at least in part from a user profile of a user account that submitted the first transaction, the operations further comprising: submitting the first transaction to a process for performing the one or more validations; determining that at least one of the one or more validations for the first transaction has failed; and retrieving the transaction object from the transaction data store; copying the invocation context from the transaction object to a second transaction; and submitting the second transaction to the process for performing the one or more validations.

20. 1. A method for resubmitting a failed database transaction record, the method comprising: receiving a first transaction to be committed to a database, the first transaction requiring one or more validations before being committed to the database, the method further comprising: writing a transaction object to a transaction data store, the transaction object including an invocation context for the first transaction, the invocation context including metadata, the metadata describing an origin of the first transaction and generated at least in part from a user profile of a user account that submitted the first transaction, the method further comprising: submitting the first transaction to a process for performing the one or more validations; determining that at least one of the one or more validations for the first transaction has failed; retrieving the transaction object from the transaction data store; copying the invocation context from the transaction object to a second transaction; and submitting the second transaction to the process for performing the one or more validations.

Images