Creating Routers with Mule SDK | MuleSoft Documentation
# Creating Routers with Mule SDK
Conceptually, routers are operations that can receive many executable routes and a set of parameters that handle the execution of one, all, or none of them.
Routes should be used for receiving multiple possible paths of execution, where the parameters of the route can be used to decide whether or not the contained processors should be executed. Stereotypes can be used in the route declaration to define are stereotypes for the contained chain. Routes do not allow complex parameters to be defined inline because the DSL content of the element will be exclusive of the parameterized operations.
## Defining a Route
First you need to declare at least one route in your module by extending the `Route` base class:
```
public class WhenRoute extends Route {
 @Parameter
 @Optional
 private boolean shouldExecute;
 public boolean shouldExecute() {
  return shouldExecute;
 }
}
```

## Declaring the Router
Next, you need to declare the router method as one of the module’s operations. Any operation receiving at least one `Route` implementation along with a `RouterCompletionCallback` is registered as a router:
```
@Extension(name = "Docs")
@Operations(ChoiceRouter.class)
public class DocsModule {
}
```

The `ChoiceRouter` class defines the following method:
```
public void choice(WhenRoute when,
          @Optional OtherwiseRoute otherwise,
          RouterCompletionCallback callback) {
 if (when.shouldExecute()) {
  when.getChain().process(callback::success, (error, previous) -> callback.error(error));
 } else if (otherwise != null && otherwise.shouldExecute()) {
  otherwise.getChain().process(callback::success, (e, r) -> callback.error(e));
 } else {
  callback.success(Result.builder().build());
 }
}
```

Above, you can see how a router is declared and how the routes are conditionally executed based on their configuration. Route execution is performed through their chain, exactly as though each route was an scope by itself.
Using the router consists of configuring the router parameters and then adding each route declaration with its own parameters:
```
<flow name="logDecoratorSampleFlow">
  <docs:choice>
   <docs:when shouldExecute="#[payload != null]">
    <http:request config-ref="config" path="/" method="GET"/>
   </docs:when>
   <docs:otherwise>
    <logger message="Payload was null"/>
   </docs:otherwise>
  </docs:choice>
</flow>
```

This will execute the `http:request` operation contained by the `when` route every time the `payload` is not null. If a null `payload` arrives, the fallback `otherwise` is executed.
## Void Routers
**Available since version 1.1**
You might need to create a router that at the end of its execution leaves the event and message the same as it was before the execution of the router. This type of router is called Void Router.
To implement a Void Router, the method needs to have an argument of the `VoidCompletionCallback` type instead of `RouterCompletionCallback`. You use this callback the same was as before (with the `success` and `error` methods), except in this case, `success` does not receive any parameter.
## Restrictions
The following restrictions apply.
### Config-less and Connection-less
Routers have some restrictions that differentiate them from operations. By definition, routers are not allowed to depend on or receive a particular configuration or connection.
### Always Non-Blocking
All routers have to be defined as a `void` method receiving a `RouterCompletionCallback` for communicating its result. This means that all routers are non-blocking by default.