Skip to Main Content

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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Workspace App Connect
Created by Guest
Created on May 15, 2023

When throwing an error in esql, and no backout queue is created, DLQ message will contain a DLQ header

If we are throwing an error in our esql, can we get a DLQ message to contain an appropriate DLQ header instead of a blank header? Most of our input queues do not have a backout queue defined, so errors would go to the DLQ. We want to ensure a DLQ header is placed on the message when the msg goes to the DLQ.

Idea priority Medium
  • Admin
    Ben Thompson
    May 24, 2023

    Idea review. Thank you for taking the time to raise this suggestion. When using catch / fail logic within a message flow which is triggered by an MQInput node reading from a queue, then the action of writing a backed-out message to the DLQ ia an option of last resort (only to be undertaken where backout threshold has been exceeded or no backout queue defined). Given this, typically we would expect users to either write logic in a catch branch or utilise the backout option rather than rely on a DLQ ... however, that said as discussed in the case that you raised with support, we could potentially inject a reason code in to a DLQ header. Having had a brief look at the source code in this area (connector framework) unfortunately we don't have an easy method of accessing and recovering the initial exception information (about why the flow hit an exception before the rollback was attempted)... So, given the complexity of the required implementation, and the fact that existing behaviours with the DLQ processing are very well and long established (this is the first time we're aware of this topic being raised), it is unlikely that this request will receive attention soon, but we are supportive of the concept nevertheless and as always we're keen to hear from the community either through votes or comments so that we can better judge the popularity of the suggestion. Status is updated to Future Consideration.