Transition Execution in BPUA

Introduction

The business process section of this site explains that a process evolves through transitions. BPUA explains how those transitions are executed in software without losing correctness.

This page follows a single transition from the moment it is requested to the moment the updated process state becomes available again.

The Execution Flow

In a BPUA-based system, transition execution typically follows this sequence:

A trigger (user action, system event, or external request) asks the process to perform a transition.
The request, as a transition context, is delivered to the Business Process Unit that owns the process state.
The Business Process Unit routes the transition context through the pipeline of application-layer transition handlers, where each transition handler may internally perform validation, execute layer-specific work, and update the transition context before the context is passed to the next layer.
The new process state becomes the authoritative state of the Business Process Unit.
The observation layer reflects those changes to the user interface.

How This Corresponds to the Earlier Business Process Model

The "Introduction into Business Process" chapter describes process execution as:
Current State -> Transition -> New State

In BPUA, the same idea becomes architecturally explicit:
Current Owned State -> Request Transition Context -> Pipeline of Activities -> Updated Transition Context -> New Owned State

The conceptual model does not change. BPUA simply makes each step an explicit architectural responsibility.

The Role of the Business Process Unit

The Business Process Unit is the authoritative owner of the running process segment. It is responsible for preserving continuity of state across transitions.

This is important because the process state must survive more than one operation. The system may need to refresh data, accept edits, reject edits, apply save results, or route to the next step without allowing unrelated components to become the hidden owners of state.

The Role of the Transition Context

A transition cannot execute correctly if it receives only a fragment of the information it needs. It requires a complete and structured context containing business data, request metadata, identifiers, and any additional information required by the transition pipeline.

This is why BPUA relies on an explicit transition context container. In the pages that follow, POCO DataSet is presented as one such container because it can carry multiple related tables together with metadata, row states, and merge semantics.

The Pipeline of Activities in BPUA

The "Introduction into Business Process" chapter describes Transition Execution Pipeline as a sequence of multiple kinds of logic participate in each transition. In a BPUA-based system, this pipeline remains intact and becomes executable.

State logic determines which transition is valid and can be executed in the current state.
Business logic applies the business rules that determine the target state of business process unit.
Data processing logic shapes and enriches transtition contex by information required during execution.
Data access logic loads or saves data required by the transition.

The difference is that BPUA gives this pipeline a stable owner and a stable context. The work is no longer scattered across unrelated technical layers.

Execution Layer and Observation Layer

BPUA also makes an important distinction between execution and observation.

The execution layer owns and mutates the authoritative process context. The observation layer presents that state to the user interface. This means the UI can react to changes without becoming the place where process correctness is enforced.

This distinction is especially important for long-lived business processes, where screens may change while the process state must remain coherent.

Why This Matters in Real Systems

Enterprise systems may fail not because the business rules are wrong, but because the transition execution model is unclear. State is duplicated, context is incomplete, refresh destroys edits, and save results are merged unpredictably.

BPUA prevents these problems by ensuring that every transition has:

a clear owner,
a clear current state,
a well-defined transition request,
a structured context container, and
an explicit execution pipeline.

Summary

A business process transition is not only a change in data.

It is a controlled execution step that moves a process from one valid state to another through an explicit context and an explicit pipeline of logic.

That is the role played by BPUA. It turns the state-and-transition model introduced earlier into a disciplined runtime architecture that can support real business software over time.

Table of Content Business Process Unit Architecture

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.