Transition Routing

Introduction

Transition routing is the mechanism that dispatches a transition request to the transition handler identified by the current request metadata. In the current architecture this responsibility belongs to TransitionContextRouter.

The important point is that the router should not decide the meaning of the next step. It should not decide whether the request must move to the next application layer, remain in the current layer, or switch to another use case. Those decisions belong to the application that prepares the transition context before routing begins.

The router should only be responsible for how the request is dispatched after the destination has already been written into ITransitionContext.RequestMetadata.

How the Router Works

TransitionContextRouter is a BPUA orchestration service. Once a transition context has been prepared for routing, the router:

1. reads the current ITransitionContext,
2. reads the current IRequestMetadata,
3. builds the transition handler key from that metadata,
4. resolves the matching transition handler by using the application services registry,
5. creates the instance of handler and executes the handler,
6. returns the resulting ITransitionContext.

This keeps the router generic. It does not need separate logic for next-layer progression, same-layer redirection, or cross-use-case routing. It only needs a correctly prepared transition context.

Who Decides the Destination

The destination is decided before the router is called. That preparation may happen in different places depending on the scenario.

Explicit Routing Actions

Some methods explicitly define routing intent (for example: SendRequestToApplicationNextLayer). These methods may directly modify request metadata and then trigger routing.

Business Requests (Routing by Rules)

Other methods express only a need (for example: GetDepartmentLookup). They do not know the destination. Routing is resolved using a routing rule dictionary based on:

• source handler type
• event name

These two scenarios have different navigation policies, but they can still use the same router because the router is not responsible for deciding the policy.

Layer Progression

The current application layers are still defined by BPUAApplicationLayers:

SL -> BL -> DPL -> DAL

This progression remains important, but it should be understood as a navigation policy, not as the core responsibility of the router itself. When a request must advance from one layer to the next, that decision should already be reflected in the request metadata before the router dispatches the request.

Why This Matters

This separation makes the architecture cleaner. Transition handlers remain focused on their own work. Application use cases can decide where the request must go next. The router remains a reusable dispatching mechanism.

It also allows one routing mechanism to support different navigation scenarios without embedding all routing rules into the router itself. The router stays small, generic, and reusable, while the system remains free to add new navigation policies later.

Summary

Transition routing is the runtime dispatch mechanism of the transition execution pipeline.

The router should dispatch according to prepared request metadata, but it should not decide the destination itself.

By separating destination selection from dispatching, Business Process Unit Architecture keeps routing generic, supports both next-layer and same-layer redirection, and preserves a clear boundary between navigation policy and orchestration.

Table of Content BPUA Chapter Previous: Service Registry Next: Use Case Assemblies

 

---

Business Process Programming in .Net
© 2004-2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.