An user must upload the async-api to Workflow Hub so that the schema content can be made available to the workflows. This is done using the Schema tab in the Workflow Hub UI.

Following is a sample async-api schema used for VMware Telco Cloud Service Assurance integration. 
Async API Schema for Kafka Integration
asyncapi: 2.1.0
id: urn:com:vmware:sebu:tca:wfh:tcsaintegration
info:
  title: TCSA Integration Message
  version: 1.0.0
  description: |
    This file describes the API through which WFH would report the status of workflows to TCSA.
  termsOfService: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/product/vmware-product-guide.pdf
  license:
    name: Vmware License
    url: https://www.vmware.com
  contact:
    email: [email protected]
    name: VMware
    url: https://www.vmware.com
 
servers:
  local-kafka-plain:
    url: 'kafka_plain:29092'
    protocol: kafka
    protocolVersion: '7.4.0-ccs'
    description: This kafka broker is unencrypted and has no authentication
  local-kafka-sasl-plain:
    url: 'kafka_secure:29092'
    protocol: kafka
    protocolVersion: '7.4.0-ccs'
    description: This kafka broker is unencrypted but uses SASL authentication to authenticate producers/consumers
    bindings:
      sasl_username: admin
      sasl_password: YWRtaW4tc2VjcmV0
      sasl_mechanism: PLAIN
      security_protocol: SASL_PLAINTEXT
 
defaultContentType: application/json
 
channels:
  tcsastatuschannel:
    bindings:
      kafka:
        topic: tca-stages
    description: This channel is used by WFH to report the progress of the workflow
    publish:
      operationId: sendupdatetotcsa
      summary: Sends update to TCSA
      description: workflows can use this schema to send updates to TCSA about the progress of WF execution
      message:
        payload:
          type: object
          properties:
            site_id:
              type: string
            fsm_state:
              type: string
            fsm_status:
              type: string
              pattern: '^(Started|Ended|Failed)$'
            error_msg:
              type: string
              pattern: '^(None|AIR|CAAS|CNF|ZTP).+$'
            timestamp:
              type: string
              format: date-time
            additional_data:
              $ref: "#/components/schemas/additionaldata"
          required:
            - site_id
            - fsm_state
            - fsm_status
            - error_msg
            - timestamp
 
components:
  schemas:
    additionaldata:
      type: object
      properties:
        task:
          type: string
        task_status:
          type: string
        event:
          type: string
        runId:
          type: string
        clustername:
          type: string
        dashboard:
          $ref: "#/components/schemas/dashboard"
        logs:
          type: string
    dashboard:
      type: object
      properties:
        aio:
          type: string
        csr_server_type:
          type: string
        dag_run:
          type: string
        du_vendor:
          type: string
        market:
          type: string
        region:
          type: string
        server_model:
          type: string
        siteId:
          type: string
  securitySchemes:
    kafka_security:
      type: plain
The main section of the schema are as follows:
  • servers: In the servers section, the details of the endpoints for communication are provided. The same schema can be used to send messages to multiple Kafka servers. The authentication details of the Kafka server are also provided along with the server details. For example, see server local-kafka-sasl-plain. Other server-related parameters can be passed under the bindings, and they must correspond to librdKafka configuration parameters. The configuration parameters exposed in librdkafka use the "." between words of the variable. For example, "builtin.features", "client.id", and so on. In the async-api schema, the "." must be replaced by "_".
    Note: The server URLs must be modified to suit your environment. The Kafka server must be up and available.
  • channels: Channels describe the communication protocol between the peers. While multiple channels can be defined, each with its message format, the VMware Telco Cloud Service Assurance integration uses a single message format. Consequently, a single channel is defined in the message. A channel can have two operations - publish and subscribe. Publish allows the workflow to publish events, while subscribe allows the user to receive events and act on it in the workflow. As of WFH 3.0, only publish is supported.
  • topic: Topics can be defined in the channel bindings. If a topic is NOT defined, then the operationId is used as the topic name. The topic must be pre-created on the Kafka brokers to receive the message.
  • operationId: An operation must be configured with an operationId (in the example, the value of this operationId is sendupdatetotcsa). The workflow refers to the operation to be performed using the operationId.
  • message: The message→payload describes the schema of the message format. The messages can contain primitives and objects. The Workflow Hub can recursively work through the objects and generate the message according to the chosen schema. A message field cannot be a json array as this is unsupported in the workflow hub. Similar to Openapi, some fields can be required and some can be optional. Similar to OpenAPI, an object can refer to component/schema. Any field that is of type "string" can be checked to fit a specific pattern using regex matching. The parameter "pattern" must be a regex expression. For example, in the message format above, the field error_msg contains an error code. As this is a predefined error code, it starts with "AIR", "CNF", "ZTP" or when the workflow is successful "None". The async-api checks to see if the received arguments match the pattern described.