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 Submitted
Workspace DataPower Gateway
Created by Guest
Created on Sep 7, 2026

Probe in new UI is lacking critical filtering features that the old probe had/has

The new "gateway peering" probe currently lacks some filters/options to build triggers to limit whats being captured.
This is important as the currently available settings are not sufficient to clearly capture relevant SOAP requests.

The urgency of this RFE is high as the old probe settings are marked as deprecated in the Firmware v10.6.X and before and will be removed with the phase out of the old UI in v11.0.0.X
The new gateway peering probe thats available in the new UI lacks relevant filters to make up for the removal of the old probe.
This leaves us inable to accurately debug certain requests before the probe fills up.
This is unacceptable for trying to maintain multi protocol gateway services that require SOAP Header Logic to be applied (and captured).

Clarifying the scope we are talking about:

new ui - /ui/admin/Debug/Probe --> create (new probe, not the peering settings before that)

current/old ui - some mpgw --> probe settings --> add trigger

The following is an explanation in addition to the screenshot we attached:
Filters that the new probe has:

  • Trigger on client IP is the only one that exisists in the same form as before.

Filters that are incomplete/require clarification:

  • Inbound/outbound URL match can somewhat be replace by Match against path, but you could also argue that its not the same and provided less funtionality. Being able to filter specifically for either inbound or outbound (and not both at once) URL.

Filters that are missing completely:

  • Processing Type is missing completely
  • Processing Rule Match is missing completey
  • XPath Expression Match is missing completely
Idea priority High
  • Guest
    Sep 9, 2026

    What about extending it even a little bit more with:

    • JQ Exporession Match - to handle JSON palyod
    • Header Match - to filter on HTTP headers
  • Guest
    Sep 9, 2026

    What about extending it even a little bit more with:

    • JQ Exporession Match - to handle JSON palyod
    • Header Match - to filter on HTTP headers
  • Guest
    Sep 7, 2026

    Great idea - absolutely needed!

  • Guest
    Sep 7, 2026

    Great idea,

    also the trigger on specific processing/error rules would be very neat to have again so you can only capture this that run in the logic you want to see or only on errors

  • Guest
    Sep 7, 2026

    Definitly needed.

    Especially when using mulitprotocol gateways with dynamic routing and more than just basic rules.

    Imagine thousands of SOAP calls per minute where the service and routing target need to be identified dynamically and now you are only able to capture 200 at once without triggering on the content.

    Client IP often is useless because of Jumpservers, proxies or whatever else may bundle calls.

    Also path is useless, as in our case all calls are coming in via the same path.
    Triggers on backend URL matching are needed. Not just the path.