anchor.diff:  Once enabled `RoutingFunction` will be bound to input destination
   receiving all the messages and route them to other functions based on the provided instruction.
   
  +IMPORTANT: For the purposes of binding the name of the routing destination is `functionRouter-in-0`
  +(see RoutingFunction.FUNCTION_NAME and binding naming convention <<Functional binding names>>).
  +
   Instruction could be provided with individual messages as well as application properties.
   
   Here are couple of samples:
   
  -***Using message headers***
  +===== Using message headers
   [source,java]
   ----
   @SpringBootApplication
  
positive.code:     }
  }
  ----
  By default `RoutingFunction` will look for `spring.cloud.function.definition` header and if it is found its value will be treated as routing instruction.
  So in the above case the value of such header should be either `odd` or `even` (the name of the function beans) to route request to available functions.
  
  You can also use SpEL for more dynamic scenarios via `spring.cloud.function.routing-expression` header.
  For example,
  setting `spring.cloud.function.routing-expression` header to value `T(java.lang.System).currentTimeMillis() % 2 == 0 ? 'even' : 'odd'` will end up semi-randomly routing request to either `odd` or `even` functions.
  Also, for SpEL, the _root object_ of the evaluation context is `Message` so you can do evaluation on individual headers (or message) as well `....routing-expression=headers['type']`
  
  ***Using application properties***
  
  The `spring.cloud.function.routing-expression` and/or `spring.cloud.function.definition`
  can be passed as application properties (e.g., `spring.cloud.function.routing-expression=headers['type']`.
  
  Passing instructions via application properties is especially important for reactive functions since given that fact that reactive
  function is only invoked once to pass the Publisher, so access to the individual items is limited.
  
  ==== Routing FROM Consumer
  
negative.code: The destinations, 'customers' and 'orders', are created in the broker (in the exchange for Rabbit or in the topic for Kafka)
  with names of 'customers' and 'orders', and the data is published to the appropriate destinations.
  
  ===== spring.cloud.stream.sendto.destination
  
  You can also delegate to the framework to dynamically resolve the output destination by specifying `spring.cloud.stream.sendto.destination` header
  set to the name of the destination to be resolved.
  