IP Library › Granted Patent US 12688084

Granted Patent B2

US 12688084 · App. 18/901,606 · Granted Jul 21, 2026

Intelligent data flow control valve

Inventors: Mahesh Muthulankkat (Trivandrum, IN); Prabakar Paulsami (Redwood City, CA)

Assignee: Oracle International Corporation

G06F11/0793 G06F11/0709 G06F11/30 H04L67/60 H04L69/321

View Patent ↗

Loading inventors, assignments & file history…

Monitor This Case

Get email alerts when status or documents change.

Order Certified Copies

Most orders are placed with the USPTO same day — all within 24 business hours.

Order via The Patent Place →

Pre-filled with this patent's details

Quick Facts

Patent No.: US 12688084
App. No.: 18/901,606
Granted: Jul 21, 2026
Kind: B2

External Links

USPTO Patent Center↗ Full Patent PDF↗

Abstract

A system for intelligent data flow control monitors an activity stream of an integration layer that processes events from an upstream system and transmits data to a downstream system. Upon detecting a recoverable error between the integration layer and the downstream system, the system instructs the upstream system to pause sending additional events. The system continues monitoring the activity stream to detect when the recoverable error is fixed. Once the error is resolved, the system instructs the upstream system to resume sending events to the integration layer. This approach prevents data loss during temporary system disruptions while maintaining efficient event processing flow.

Claims (60)

1 . One or more non-transitory computer-readable media comprising instructions which, when executed by one or more hardware processors, cause performance of operations comprising:

monitoring an activity stream of an integration layer that is configured to (a) receive events from an upstream system, via an event queue of the upstream system that buffers the events before transmission to the integration layer, and (b) transmit data to a downstream system responsive to the events;

detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;

responsive to detecting the recoverable error: instructing the upstream system to pause sending additional events to the integration layer, causing the upstream system to retain a paused event in the event queue of the upstream system;

storing, in a failed events queue of the integration layer, a failed event attributable to the recoverable error;

after instructing the upstream system to pause sending additional events to the integration layer:

attempting reprocessing of the failed event from the failed events queue of the integration layer;

detecting that reprocessing of the failed event was successful;

based at least in part on detecting that reprocessing of the failed event was successful, detecting that the recoverable error is fixed; and

responsive to detecting that the recoverable error is fixed: instructing the upstream system to resume sending additional events to the integration layer, causing the upstream system to release the paused event from the event queue of the upstream system to the integration layer.

2 . The one or more non-transitory computer-readable media of claim 1 , wherein detecting that the recoverable error is fixed comprises:

detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

3 . The one or more non-transitory computer-readable media of claim 1 , wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

4 . The one or more non-transitory computer-readable media of claim 1 , wherein the operations further comprise:

using a machine learning model to generate a learning report comprising one or more error detection parameters for detecting recoverable errors;

wherein the one or more error detection parameters comprise one or more of a hypertext transfer protocol (HTTP) status code, an error message pattern, a count of similar continuous errors, a time window for errors, or a time needed for recovery; and

wherein detecting the recoverable error is based at least in part on the one or more error detection parameters in the learning report.

5 . The one or more non-transitory computer-readable media of claim 4 , wherein the learning report is user-reviewable, and wherein the operations further comprise receiving user input comprising one or more user adjustments to one or more error detection parameters in the learning report.

6 . The one or more non-transitory computer-readable media of claim 4 , wherein the operations further comprise: training the machine learning model to identify recoverable errors.

7 . The one or more non-transitory computer-readable media of claim 1 , wherein the recoverable error comprises at least one of: a planned outage, an unplanned outage, a password expiration, or a permission issue.

8 . The one or more non-transitory computer-readable media of claim 1 , wherein the operations further comprise routing retry requests to the integration layer based on stored instance identifiers associated with one or more failed events.

9 . A method comprising:

detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;

storing, in a failed events queue of the integration layer, a failed event attributable to the recoverable error;

after instructing the upstream system to pause sending additional events to the integration layer:

attempting reprocessing of the failed event from the failed events queue of the integration layer;

detecting that reprocessing of the failed event was successful;

based at least in part on detecting that reprocessing of the failed event was successful, detecting that the recoverable error is fixed; and

wherein the method is performed by at least one device including a hardware processor.

10 . The method of claim 9 , wherein detecting that the recoverable error is fixed comprises:

detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

11 . The method of claim 9 , wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

12 . The method of claim 9 , further comprising:

using a machine learning model to generate a learning report comprising one or more error detection parameters for detecting recoverable errors;

wherein detecting the recoverable error is based at least in part on the one or more error detection parameters in the learning report.

13 . The method of claim 12 , wherein the learning report is user-reviewable, further comprising receiving user input comprising one or more user adjustments to one or more error detection parameters in the learning report.

14 . The method of claim 12 , further comprising:

training the machine learning model to identify recoverable errors.

15 . The method of claim 9 , wherein the recoverable error comprises at least one of: a planned outage, an unplanned outage, a password expiration, or a permission issue.

16 . The method of claim 9 , further comprising routing retry requests to the integration layer based on stored instance identifiers associated with one or more failed events.

17 . A system comprising:

at least one device including a hardware processor;

the system being configured to perform operations comprising:

detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;

storing, in a failed events queue of the integration layer, a failed event attributable to the recoverable error;

after instructing the upstream system to pause sending additional events to the integration layer:

attempting reprocessing of the failed event from the failed events queue of the integration layer;

detecting that reprocessing of the failed event was successful;

based at least in part on detecting that reprocessing of the failed event was successful, detecting that the recoverable error is fixed; and

18 . The system of claim 17 , wherein detecting that the recoverable error is fixed comprises:

detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

19 . The system of claim 18 , wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

20 . The one or more non-transitory computer-readable media of claim 1 , wherein detecting the recoverable error comprises detecting the failed event.