Skip to content
Tutorial1/5

1. Scaffold the component

Create the empty transactional Component and run its initial tests.

Create the component directory and render the template into it:

Terminal window
mkdir order-sync && cd order-sync
intropy int create transactional -n OrderSync -s organization=Fluxia -s empty=true -o . --no-input
fetching integrio-intropy/intropy-templates@v2.0.0
created . from integrio-intropy/intropy-templates@v2.0.0 (template transactional)

Create the order-sync directory first. Chapter 4 creates a sibling system host that finds the Component by this folder name.

Use your own organization in place of Fluxia. empty=true leaves the send steps and platform-service wiring for you. To inspect the template parameters:

Terminal window
intropy template show transactional
Transactional Integration (transactional) @ integrio-intropy/intropy-templates@v2.0.0
.NET job that polls a local source folder, publishes via in-memory Dapr pub/sub, and writes the transformed result to a local destination folder.
Tags: [example dotnet dapr transactional]
Parameters:
* name — Project name [string]
PascalCase identifier used for the .NET project, root namespace, and assembly. …
* organization — Organization [string]
PascalCase name of the organization the integration runs for. …
idempotencyAppId — Idempotency service app-id [string]
… Only wired when empty is false.
default: idempotency-service.services
businessIncidentsAppId — Business incident service app-id [string]
… Only wired when empty is false.
default: business-incident-service.services
empty — Empty bodies [boolean]
When true, strip sample business logic from pipeline step bodies and omit the
idempotency/business-incident service wiring. …
default: false
(* = required)

Parameter descriptions are shortened here; the command prints them in full. The two app-id parameters only apply when empty=false; chapter 5 wires the services by hand instead.

Open the directory in your editor. For VS Code:

Terminal window
code .

On Windows, run code . from the WSL shell. VS Code opens the folder through its WSL extension, so the editor, its terminal and the .NET tooling all work against the WSL filesystem. The first run installs the VS Code server inside WSL.

The scaffold creates one .NET job, its send pipeline, and tests:

order-sync/
├── OrderSync.slnx
├── Taskfile.yml # task build / test:unit / test:integration
├── Dockerfile # .NET 10 chiseled runtime, app only
├── AGENTS.md # project facts for AI assistants
├── CLAUDE.md # points Claude Code at AGENTS.md
├── README.md # how to build, test, and run the component
├── .intropy/scaffold.json # what was rendered, from which release
├── src/
│ ├── Program.cs # build DI, resolve the job runner, run
│ ├── appsettings*.json # base and Development configuration
│ ├── Configuration/
│ │ ├── Composition.cs # every service registration, shared with the tests
│ │ └── Constants.cs # component, port, and context-key names
│ ├── Model/ # In, Line, Out — empty shells until chapters 2–3
│ └── Send/ # SendRoute, and Deserializer → … → Sender with bodies that throw
└── test/
├── OrderSync.Test.Unit/ # one test class per send step, empty for now
└── OrderSync.Test.Integration/ # receive side, send pipeline, and a composition smoke test

Before writing code, check these files:

  • src/Send/ compiles but throws NotImplementedException.
  • src/Send/SendRoute.cs chains the send steps into the send pipeline. Chapter 5 extends it.
  • src/Configuration/Composition.cs contains the registrations used by the app and tests. services.AddTransactionalIntegration() registers the receive side. It is framework code: it sweeps the source folder, publishes each file to the internal queue, and deletes the file once it is on the queue.
  • .intropy/scaffold.json is read by intropy sys create in chapter 4.

Build and run the initial test suite:

Terminal window
dotnet build
dotnet test

The build succeeds with one expected warning:

src/Send/Sender.cs(10,34): warning CS9113: Parameter 'fileAdapter' is unread.
Build succeeded.
1 Warning(s)
0 Error(s)

The warning disappears in chapter 4 when the Sender is implemented. The test suite fails by design:

Skipped! - Failed: 0, Passed: 0, Skipped: 1, Total: 1 - OrderSync.Test.Unit.dll (net10.0)
[xUnit.net] OrderSync.Test.Integration.SendPipelineIntegrationTests.Execute_WithValidMessage_WritesOutput [FAIL]
Failed! - Failed: 1, Passed: 4, Skipped: 0, Total: 5 - OrderSync.Test.Integration.dll (net10.0)

Execute_WithValidMessage_WritesOutput fails because every send step throws. It goes green in chapter 4. The receive-side and composition tests already pass.

Keep the failure. It defines the work ahead.