Skip to Main Content
Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Status Not under consideration
Workspace App Connect
Created by Guest
Created on Aug 17, 2017

Database Sequential Read Node

We need a Database Sequential Read (DSR) Node similar to the File Input Node. We would identify the particular view name (possibly allowing for different sort sequences of the database). Instead of doing a SELECT * which would use excessive memory, a DSR Node would only feed one row at a time into memory for processing, similar to a File Input Node, thereby limiting memory. And End of Database Terminal would be similar to an End of File Terminal allowing for appropriate End processing. This would give IIB the ability to stream a database through a flow without consuming excessive memory.

Idea priority High
RFE ID 109183
RFE URL
RFE Product IBM App Connect Enterprise (formerly IBM Integration Bus)
  • Admin
    Ben Thompson
    Reply
    |
    Jul 31, 2023

    Idea Review. As part of our policy for regularly reassessing aged ideas we have recently discussed this enhancement request again. Unfortunately, with no new comments since the last suggestion for workaround in 2020, and with only 6 votes since its creation six years ago, on this occasion it has been decided that we won't be taking this idea further forward.

  • Guest
    Reply
    |
    Oct 8, 2020

    RFE Review. Thank you for raising this RFE and apologies for the time period it has been in Submitted Status. This is an interesting suggestion. IIB/ACE has a DatabaseInput node, whose purpose is to drive a flow capable of responding to changed conditions in a database "application" table(s). This design utilises an "event table". An event table stores information about changes to application tables. The event table is a database table created by the user, generally within the same schema as the application table for which it stores events. The event table describes the type of change made to an application table, and also contains an identifier for the changed row. IIB/ACE polls the event table, and after processing a row marks it as complete. This has similar characteristics to the requested design of a DSR node - it provides the concept of a query to establish rows for processings, and lets each flow propagation deal with a smaller set of the data.
    Another option with the product in its current form would be to use a Compute node to run a SELECT statement with WHERE to return a subset of the rows (of a manageable size, potentially configurable over time, so as to not consume too much memory) from the database. Subsequent downstream flow logic could iteratively loop over the returned rows and PROPAGATE them to the rest of the flow one at a time. In this fashion, a single flow thread could be used to process multiple rows one after another, and find a balance between speed of doing a single lookup versus memory cost of volume of data returned.
    Perhaps you have already explored these options, but we felt worth mentioning as they may prove fruitful for other readers passing through this RFE. Despite the relief these may provide, we feel there is sufficient merit in the idea to move the status to Uncommitted Candidate and we will continue to monitor for interest/popularity.