Enterprise Adapter Event Staging for Reliable Delivery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current adapters fail to ensure reliable delivery of Enterprise Information System (EIS) events to clients, often resulting in inconsistent data, missed updates, and inefficient data management due to lack of confirmation mechanisms, dynamic client handling, and recovery protocols.

Innovation Solution

A system with a logic unit comprising polling, staging, delivery, and confirmation modules, utilizing a transaction service for guaranteed once-and-only-once event delivery, with capabilities for holding and redelivering events to unavailable clients and integrating with XA-compliant databases for distributed transaction management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If a publisher/subscriber system is used to transmit EIS events to clients, then clients can receive real-time updates, but clients may miss events when offline or unresponsive

Engineering Contradiction:
ImproveReal-time update deliveryVSAvoidEvent delivery assurance
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The adapter performs preliminary actions by queuing events in a persistent storage mechanism before client consumption. When clients are offline, events are staged and held in the adapter's event queue, ready for delivery once the client becomes available. This preliminary staging ensures no events are lost during client unavailability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback through acknowledgment mechanisms where clients confirm receipt of events. The adapter tracks which clients have received which events and uses this feedback information to determine whether to retransmit events, ensuring reliable delivery even when clients are intermittently unavailable.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If events are broadcast to all clients, then all clients receive updates, but multiple copies of the same event may be sent causing data inconsistency and waste

Engineering Contradiction:
ImproveMulti-client distributionVSAvoidData integrity
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The adapter maintains state information about which clients have received which events. Before broadcasting an event, the adapter checks this state to determine which clients need the event. This feedback-driven approach ensures each client receives exactly one copy of each event, preventing both data inconsistency and unnecessary duplication.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system applies different delivery behaviors to different clients based on their individual states. Rather than a uniform broadcast to all clients, the adapter tailors event delivery to each client's specific situation (online/offline, has-received/has-not-received), optimizing both data integrity and resource utilization.

Inventive Principle:
Principle #3Local quality

3Productivity

If adapters broadcast events without considering client status, then events are sent out, but clients may get out of sync with inconsistent data

Engineering Contradiction:
ImproveEvent transmission speedVSAvoidClient synchronization
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The adapter continuously monitors client status and uses this feedback to control event transmission. Clients are tracked as available or unavailable, and event delivery is adjusted accordingly. This ensures clients remain synchronized with the EIS without unnecessary transmissions that would waste resources.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The event transmission system is dynamic rather than static. The adapter adapts its behavior based on real-time client status, switching between immediate delivery, queuing for later delivery, or suppression of redundant deliveries. This dynamic approach maintains synchronization while optimizing transmission efficiency.

Inventive Principle:
Principle #15Dynamics

4Device complexity

If current adapters are used without recovery protocols, then simple event transmission occurs, but events may be lost during unexpected problems

Engineering Contradiction:
ImproveAdapter simplicityVSAvoidEvent delivery assurance
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The adapter implements beforehand cushioning through persistent event queuing and checkpointing mechanisms. Events are staged in durable storage before client consumption, creating a buffer that protects against data loss during system failures. Recovery protocols use these pre-established checkpoints to resume normal operation without losing events.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

The system implements recovery by discarding failed delivery attempts and recovering through retransmission. The adapter tracks which events were successfully delivered and which failed, automatically recovering from failures by retransmitting only the necessary events after system recovery, rather than maintaining complex preventive measures throughout operation.

Inventive Principle:
Principle #34Discarding and recovering

Data Source

PatentUS8301750B2Apparatus, system, and method for facilitating communication between an enterprise information system and a client
Publication Date: 2012.10.30 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US8301750B2 patent drawing
  • US8301750B2 patent drawing
  • US8301750B2 patent drawing

AI summary

An apparatus, system, and method are disclosed for assuring delivery of an Enterprise Information System (EIS) event to a client. An adapter apparatus polls at least one EIS for an event. The event is staged to a staging table, consisting of an XA-compliant database, in preparation for delivery to the client. The status of the event is marked and the event is delivered to the client. Events delivered to clients that are unresponsive or otherwise unavailable are held until the clients become responsive and then the events are delivered. Delivery of events is confirmed using a transaction service.