Source in the application context so
A module can have multiple input or output channels all defined either as @Input and @Output methods in an interface (preferrable) or as bean definitions. Instead of just one channel named "input" or "output" you can add multiple MessageChannel methods annotated input. or output. and the names are converted to external channel names on the broker. The external channel names are the spring.cloud.stream.[input|output]ChannelName plus the MessageChannel bean name, period separated. In addition, the bean name can be input.[queue|topic|tap]:* or output.[queue|topic]:* (i.e. with a channel type as a colon-separated prefix), and the semantics of the external bus channel changes accordingly (a tap is like a topic). For example, you can have two MessageChannels called "output" and "output.topic:foo" in a module with outputChannelName=bar, and the result is 2 external channels called "bar" and "topic:foo.bar".
A module can have multiple input or output channels all defined either as @Input and @Output methods in an interface (preferrable) or as bean definitions. Instead of just one channel named "input" or "output" you can add multiple MessageChannel methods annotated @Input or @Output and the names are converted to external channel names on the broker. The external channel names can be specified as properties that consist of the channel names prefixed with spring.cloud.stream.bindings (e.g. spring.cloud.stream.bindings.input or spring.cloud.stream.bindings.output). External channel names can have a channel type as a colon-separated prefix, and the semantics of the external bus channel changes accordingly (a tap is like a topic). For example, you can have two MessageChannels called "output" and "foo" in a module with spring.cloud.stream.bindings.output=bar and spring.cloud.stream.bindings.foo=topic:foo, and the result is 2 external channels called "bar" and "topic:foo".
All output channels can be also tapped so you can also attach a module to a pub-sub endpoint and listen to the tap if you know the module metadata. To tap an existing vanilla module you need to know its outputChannelName and the tap name is then tap:<outputChannelName>, so you can listen to it on an input channel named input.topic.tap:<outputChannelName>. The tap is only active if you explicitly ask for it: you can do that by POSTing to the HTTP endpoint /taps/<channelName> (where the channel name can be the internal or external name, e.g. "output" or the external name mapped to the output channel).
All output channels can be also tapped so you can also attach a module to a pub-sub endpoint and listen to the tap if you know the module metadata. To tap an existing vanilla module you need to know its outputChannelName and the tap name is then tap:<outputChannelName>, so you can listen to it on an input channel named topic.tap:<outputChannelName>. The tap is only active if you explicitly ask for it: you can do that by POSTing to the HTTP endpoint /taps/<channelName> (where the channel name can be the internal or external name, e.g. "output" or the external name mapped to the output channel).
To tap an existing output channel in an XD module you just need to know its group, name and index, e.g.
@@ -623,7 +624,7 @@ The main set of samples are "vanilla" in the sense that they are not deployable