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 review. Thank you for taking the time to raise this suggestion. As noted, when specifying an event filter, you can use xpath expressions to examine a value held in part of the logical message tree in order to decide whether or not to emit the event. Details here:
https://www.ibm.com/docs/en/app-connect/12.0?topic=basics-example-xpath-expressions-event-filtering
This capability is incredibly flexible because the choice of whether to emit an event can be made on a message-by-message basis as opposed to a fixed setting for an entire environment. In the proposed idea, the decision to emit an event is instead based upon the value of a message flow's user-defined property. Similarly, one could imagine using references to other static values such as the name of the flow, its containing application or the name of the integration server to which it is deployed. These kind of environmental static values are available in ESQL and graphical data maps. In concept we understand the requirement along these lines and we agree it would bring additional benefit. In the meantime of course, it would be possible to apply a workaround of sorts and take these kind of static environmental values and place them into the logical tree using a prior message flow node and so be able to reference them in later nodes when deciding whether to emit a monitoring event. This would only work in message flow nodes downstream so wouldnt be able to be applied directly to an input node. So, whilst somewhat of a fringe requirement we're happy to move it to Future Consideration status and test the appetite from the user community - this is the first time this has been raised many years after monitoring events have been available, but its never too late to make things *even* better of course ;o)