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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
Thank you for the additional details and quick response. It sound like this is mostly the need to be able to debug the flow while in development. IBM API Connect already has the ability to view tracing of the payload, headers, other meta-data in the API Connect Test tab of the API Editor (https://www.ibm.com/docs/cs/api-connect/10.0.1.x?topic=api-reviewing-response-trace) Deleting or disabling policies should not be required to review the output(s) of an action the occurs earlier in the flow.
Having individual policy toggles could introduce unexpected behaviors when disabling a policy that is part of a sequence and/or branch logic. For example Req-> Map(1)->Invoke -> Map(2) -> Response. Disabling the Invoke would most likely lead to the following Map(2) to fail if we are 'skipping' the Invoke and passing the results of Map(1) into Map(2). Would the ability to set a policy to have a breakpoint in the Assembly accomplish what you are trying to accomplish? In the above example setting a breakpoint after the Map(1) to stop the rest of the Assembly from completing?
Let's take an example of invoking policy - I configured that policy with block header, allow headers, cache keys and response in a custom variable, etc.. if I delete and re-add, I have to configure again, but if disable is present, I can disable this policy and test my flow and enable it again. It would save my time and make the debugging easier.
As a workaround - What I am doing currently is creating a catch block and dragging it there to achieve disable function.
Take an example of a Map policy with a large JSON payload; deleting the policy and re-adding are not a good user experience.
Thank you for the request, we would like some more details on what type of scenario you are deleting and re-adding policies during testing. What does deleting the policy provide in your testing process.