When nesting an activity with multiple outcomes, you can wire each terminus to a different route.

For example, an output using Track(:create) will snap to the next possible task that is “magnetic to” :create. That’s how tracks or paths are created.

Semantics are mostly relevant for nesting

Remember, in a railway activity each task has two standard outputs with the “semantics” success and failure.

By using Output(:semantic), you can select an existing output of the task and rewire it.

Why don’t we put the “create user” task onto the failure track, and in case of successfully persisting the new user, we deviate back to the happy path?

the Activity component is the heart of TRB

To implement such an activity, we only need to rewire the second step’s failure output to a new terminus.

Since you can reference outputs by their semantic, you as a modeller only connect conceptual termini to ongoing connections!

it’s a bit as if the following wiring is applied to every task added via #step

Additionally, you may add debugging steps, error handler or rewire the conditions dynamically without touching the original snippet.

Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.

Knowing about the wiring mechanics in Trailblazer is one thing. However, the real fun starts with nesting activities. That’s when the ideas of encapsulation, interfaces and reducing dependencies really come into play.

Nesting an activity into another is a bit like calling a library method from another method

the explicit modelling has one massive advantage: all possible outcomes of the nested activity are visible and have to be connected in the outer diagram

or even configure its taskWrap

Please note that the I/O DSL is only providing the most-used requirements. Feel free to use the low-level taskWrap API to build your own variable mapping with different scoping techniques.

step :direct_debit

Activities are a necessary abstraction on top of Ruby.

An operation has two invocation styles. This is the only difference to an Activity.