Customization points ​
TPF generates the baseline runtime and adapters, but you still have clear places to inject project-specific behavior when needed.
Where customization usually happens ​
Orchestrator runtime ​
The orchestrator is generated, but you can extend or replace parts of it when you need stricter control over execution flow. See Orchestrator runtime extension for the deeper guide.
Common cases:
- Custom input provisioning (CLI, files, queues, APIs).
- Extra logging/metrics around pipeline execution.
- Retry and backoff policies tailored to your domain.
You can also bypass OrchestratorApplication and drive the pipeline through custom REST orchestration logic.
Reactive services ​
Reactive step services expose a process() contract. You can wrap that behavior without changing pipeline contracts. See Reactive services extension for the detailed contract.
Common cases:
- Add Micrometer timers/counters.
- Validate inputs before processing.
- Map infrastructure errors to domain-friendly failures.
- Add rate limiting or circuit breaking.
Client steps ​
Generated client steps are used by the orchestrator to invoke backend services. They are a good place for call-specific concerns. See Client steps extension for generated client-step customization.
Common cases:
- Add metrics around remote calls.
- Apply retries/fallbacks.
- Enrich headers or request metadata before invoking gRPC/REST.
REST resources ​
Generated REST resources are regular classes and can be extended safely. See REST resources extension for endpoint-level customization.
Common cases:
- Add custom endpoints next to generated
/process. - Customize exception mapping.
- Inject additional cross-cutting collaborators.
Practical guidance ​
- Start from generated behavior first; customize only where you have a clear operational or domain need.
- Keep custom logic close to the relevant boundary (orchestrator, service, client step, resource).
- Prefer wrapper/decoration patterns over invasive edits to generated code.