SOAPInput node reports time out (BIP3907I) when flow already deliberatly ends without invoking SOAPReply node

When a SOAP-over-HTTP Request is received by an IIB Message Flow (via a the SOAPInput node) and the flow decides to terminate processing without sending a response back via the SOAPReply node , the SOAPInput node ultimately generates a BIP3907I error.

I understand that in most cases, this is a desired behavoir. But we have a use case where we want to deliberately terminate the flow without sending a response back via the SOAPReply node.

Please review PMR 19205.082.000. This has been discussed in detail there. Especially the IBM Update 3/21/16 3:26 PM entry. Which identifies that IIB has a "A separate back ground process has a table of SOAP reply ids and if a reply was sent." and proposes a solution that I feel is convoluted and prone to errors. Expecially in multi instance implementations.

Desired solution is a (for lack of a better word) SOAPNoReply node or some run time settable option on the SOAPReply node. This node would signal IIB that a SOAP reply will not be sent by this execution of the flow and do whatever is needed to 'flag' the background process. Thus preventing the SOAPInput node from timing out and consuming resources until it does time out.

Plain and simple. I want the ability to signal IIB that the execution of the flow is complete and that a SOAPReply is not going to be sent.

In some ways this is similar to RFE 66470 (http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=66470) as they both are related to a timeout in the SOAPInput node. But different in that I want to be able to, at run time, is signal IIB that the instance of the flow executing does not intend to send a SOAP reply. Therefore preventing the SOAPInput node from timing out and reporting the timeout.