Enhancement: Generate channels values

[bibiboss]

In the asyncapi files, we have to declare the channels on which we want to exchange.
This value can be useful, for example in MQTT you might use this channel to have a pattern to which to subscribe to (same for kafka).
Same thing when you want to publish a message.

I don't know how the parameters could be handled tho'

Any thoughts?

[jemacineiras]

Hi @bibiboss,

i do not totally follow you, can you provide an example?

Cheers

[bibiboss]

Hello @jemacineiras

Here a sub part of an asyncapi document

asyncapi: 2.5.0
info:
  title: Organization API MQTT interface contract
  version: '1.0.0'
  description: |
    This document describe the input and output of the component "organization-api".

defaultContentType: application/json
channels:
  events/public/output/{organizationId}:
    description: The output topic
    parameters:
      organizationId:
        $ref: '#/components/parameters/organizationId'
    subscribe:
      operationId: output
      traits:
        - bindings:
            mqtt:
              retain: true
      message:
        $ref: '#/components/messages/output'
# more definition

(Full definition of this sample in issue #312 )

The channel events/public/output/{organizationId} is never reachable in the generated code.

I think it would be good to have in the generated code to have access to a representation of this channel.
For example a piece of code like

public enum InputChannel {
  OUTPUT_CHANNEL("events/public/output/(.*)");
}

In this example, I propose the following (that is up to discussion):

• Channels would be generated in a enum that follows the convention [operationId]Channel
• The value of the enum is ready to be used as a regular expression. Maybe another value is to be determined (like events/public/output/ that match the prefix)

Is it clarifying?

[jemacineiras]

Hi @bibiboss ,

right, this type of channels are implemented only as producer using the StreamBridge. For generate the consumer we still need to work in the generation of this part. Mainly what we are build are beans for the Spring Cloud Function way of configuration.

This feature is something we are considering since when you attach your consumer to a channel you need to know which one so variables are complicated to support.
Consider this opened issue #292 if that is the same to you
Cheers

[bibiboss]

Hello @jemacineiras

Indeed, they are related, but it is not exactly the same issue.

The #292 is releated to cloud stream, kafka behaviors and pattern generation, but right now I'm working with MQTT. The channels will have different usage in my case, for instance figure out which callback to call on reception of a message based on the channel.