public class RoutingFunction implements Function<Publisher<Message<?>>, Publisher<?>>, Consumer<Publisher<Message<?>>> {
+public class RoutingFunction implements Function<Object, Object> {
. . .
}
From 1fb056edecbc377bdb43e018ecb0b69193311be5 Mon Sep 17 00:00:00 2001
From: buildmaster
You enable this feature via spring.cloud.function.routing.enabled property setting it
-to true (default is false).
-This enables RoutingFunction under the name router which is loaded in FunctionCatalog.
The RoutingFunction is registered in FunctionCatalog under the name functionRouter. For simplicity
+and consistency you can also refer to RoutingFunction.FUNCTION_NAME constant.
This function has the following signature:
public class RoutingFunction implements Function<Publisher<Message<?>>, Publisher<?>>, Consumer<Publisher<Message<?>>> {
+public class RoutingFunction implements Function<Object, Object> {
. . .
}
This allows the above function to act as both Function and Consumer.
-As you can see it takes Message<?> as an input argument. This allows you to communicate
-the name of the actual function you want to invoke by providing function.name Message header.
The routing instructions could be communicated in several ways;
In specific execution environments/models the adapters are responsible to translate and communicate function.name
-via Message header. For example, when using spring-cloud-function-web you can provide function.name as an HTTP
+
Message Headers
+If the input argument is of type Message<?>, you can communicate routing instruction by setting one of
+spring.cloud.function.definition or spring.cloud.function.routing-expression Message headers.
+For more static cases you can use spring.cloud.function.definition header which allows you to provide
+the name of a single function (e.g., …definition=foo) or a composition instruction (e.g., …definition=foo|bar|baz).
+For more dynamic cases you can use spring.cloud.function.routing-expression header which allows
+you to use Spring Expression Language (SpEL) and provide SpEL expression that should resolve
+into definition of a function (as described above).
| + + | +
+SpEL evaluation context’s root object is the
+actual input argument, so in he case of Message<?> you can construct expression that has access
+to both payload and headers (e.g., spring.cloud.function.routing-expression=headers.function_name).
+ |
+
In specific execution environments/models the adapters are responsible to translate and communicate
+spring.cloud.function.definition and/or spring.cloud.function.routing-expression via Message header.
+For example, when using spring-cloud-function-web you can provide spring.cloud.function.definition as an HTTP
header and the framework will propagate it as well as other HTTP headers as Message headers.
Using Message also allows us to benefit from `MessageConverter`s to convert incoming request to the actual input type -of the target function
+Application Properties
+Routing instruction can also be communicated via spring.cloud.function.definition
+or spring.cloud.function.routing-expression as application properties. The rules described in the
+previous section apply here as well. The only difference is you provide these instructions as
+application properties (e.g., --spring.cloud.function.definition=foo).
| + + | ++When dealing with reactive inputs (e.g., Publisher), routing instructions must only be provided via Function properties. This is +due to the nature of the reactive functions which are invoked only once to pass a Publisher and the rest +is handled by the reactor, hence we can not access and/or rely on the routing instructions communicated via individual +values (e.g., Message). + | +