This content has been marked as final. Show 2 replies
Simply ignore it.
You see, InterConnect is TRANSPORT solution, it's like a pipe.
So if one put message in a pipe, another should take it, otherwise do'nt put it.
If to say more realistically, your may need some business logis layer, wich implemented natively in Workflow or more modern - in BPEL.
In this case you always publish message from source application to Workflow (BPEL) and there inside business process you decede whether to publish forwards or simply NULL the message.
This decide point even could be implemented in Business Rules in case of using BPEL as business logic layer - so you could dynamically on the fly change the condition of receiveing message by one or another application or temporarilly disconect one of the receiving applications...
You can try and adopt of the following 2 paradigms:
1) If using a DB adapter, restrict the data before publishing the massage and then use the CBR to filter the message to the other 4 other subscribing Applications as designed – this will help to eliminate the above error or .
2) Create an adapter and point it locally/internally and use the CBR to redirect any messages that do not satisfy any of the 4 other 4 other subscribing Applications to the internal Adapter.