---
-spring:
- cloud:
- stream:
- bindings:
- output: ${spring.application.name:ticker}
-The application.yml has the mapping from channel names to external broker handles (queues, topics, routing keys, etc. depending on the broker), e.g.
---
-spring:
- cloud:
- stream:
- bindings:
- output: ${spring.application.name:ticker}
-@EnableModule is parameterized by an interface (in this case Source) which declares input and output channels. Source, Sink and Processor are provided off the shelf, but you can define others. Here’s the definition of Source
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 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".
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. 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 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.
-spring:
- cloud:
- stream:
- group: tocktap
- name: logger
- index: 0
- tap:
- group: testtock
- name: ticker
- index: 0The spring.cloud.stream.tap section tells the module runner which topic you want to subscribe to. It creates a new group (a tap can’t be in the same group as the one it is tapping) and starts a new index count, in case anyone wants to listen downstream.