Principle:Microsoft Semantic kernel Process Builder Creation
| Knowledge Sources | |
|---|---|
| Domains | Process_Orchestration, Builder_Pattern |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
The Process Builder provides a declarative, fluent interface for constructing event-driven workflows by incrementally adding steps and defining their connections through the builder pattern.
Description
Process Builder Creation is the design principle that governs how event-driven process workflows are declaratively constructed in Semantic Kernel. Rather than imperatively wiring steps together through direct method calls, the builder pattern allows developers to define the structure of a process--its steps, event routes, and termination conditions--as a series of declarative configuration statements that are materialized into an executable process graph when Build() is called.
The ProcessBuilder class serves as the central orchestration point for this construction. It maintains an internal collection of steps, each represented by a ProcessStepBuilder, and an internal map of event routes that connect step outputs to step inputs. The builder enforces several invariants during construction:
- Step name uniqueness: No two steps within the same process may share the same name. The builder validates this at the point of step registration and throws an InvalidOperationException if a duplicate is detected.
- Event route resolution: When events are wired from one step to another through methods like SendEventTo, the builder resolves the target function and parameter on the destination step at definition time, not at runtime. This provides early feedback if a route is misconfigured.
- Subprocess encapsulation: Processes can be composed hierarchically by adding child processes as steps via AddStepFromProcess. The builder manages the parent-child relationship and event boundary mapping.
The builder separates the definition phase from the execution phase. During definition, the developer declares what steps exist and how events flow between them. During execution (after Build() is called), the runtime takes over and manages the actual event dispatch and step invocation. This separation means the process graph is immutable once built, which simplifies reasoning about process behavior.
Usage
Use ProcessBuilder whenever you need to define a new process workflow. Create a new instance with a descriptive name, add steps using AddStepFromType<T>(), wire events using OnInputEvent, OnFunctionResult, and SendEventTo, and finally call Build() to produce the executable KernelProcess object.
Theoretical Basis
The Process Builder embodies the Builder Pattern applied to directed acyclic graphs (DAGs) of event-driven operations.
Builder Pattern Application: The classic builder pattern separates the construction of a complex object from its representation. In the process builder, the complex object is an event-driven execution graph:
ProcessBuilder pb = new ProcessBuilder("MyProcess")
pb.AddStep(S1)
pb.AddStep(S2)
pb.AddStep(S3)
pb.WireEvent(S1 → S2)
pb.WireEvent(S2 → S3)
pb.Build() → KernelProcess(Graph{S1, S2, S3}, Edges{S1→S2, S2→S3})
Graph Construction: The process builder constructs an execution graph where:
- Nodes are process steps (registered via AddStepFromType<T>())
- Edges are event routes (defined via SendEventTo())
- Entry points are external event handlers (defined via OnInputEvent())
- Terminal nodes are steps whose results trigger StopProcess()
The builder enforces well-formedness at construction time by resolving function targets and validating parameter names against the step's KernelFunction metadata.
Fluent Interface: The builder uses method chaining to create a readable, declarative syntax that mirrors the logical flow of the process:
process.OnInputEvent("Start")
.SendEventTo(step1) // Entry edge
step1.OnFunctionResult()
.SendEventTo(step2) // Sequential edge
step2.OnFunctionResult()
.StopProcess() // Terminal edge
This fluent style makes the process topology immediately apparent from the code, serving as both executable configuration and documentation of the workflow structure.
Immutability After Build: Once Build() is called, the resulting KernelProcess is a frozen snapshot of the process definition. The builder can be discarded or reused as a template, but the built process cannot be modified. This guarantees that the process topology remains stable throughout execution.