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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
Idea / RFE Review. Apologies for the length of time this idea has been in the status of Uncommitted Candidate / Future Consideration. As noted in the last development update, we do have a Failure action which avoids infinite retry and also resets the newxt expected sequence number, so this use case has become achieveable but currently requires the user to handle the persistence of the failed message to a queue and then its later re-reading. This could be done using the ACE Record & Replay capability and perhaps using a Timer node based message flow to control *when* the replay should be attempted. Whilst this would be possible, it is fair to acknolwedge this would be a workaround and it would be an improvement to the product to have an OOTB capability to allow a "long retry" interval to be specified and MQ details to use for the intermediate storage of the message prior to replay. It's unlikely we'll get to this soon, but remains a valid enhancement idea which we'd like to continue monitoring for support. Status is maintained as Future Consideration.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Connectivity and Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB
Thanks for raising this RFE. We have recently introduced a new Failure action to the Resequence node which avoids infinite retry, and also resets the expected sequence number so once a flow has handled the downstream exception, the message could be resubmitted into the resequence node. This is not quite the same as specifying a number of retries before invoking this option, so rather than rejecting the requirement on these grounds, I'll leave this open to track the possible future specification of a number of retries (and also note the Aggregate and Collector angles suggested).