Step¶

Step is a named, traceable group of processors. It behaves like a Pipeline but additionally sets the HelixStepId exchange property before running its children, so downstream metrics, traces, and logs can identify which logical step the exchange is in.

Processors in this file¶

NewStep¶

YAML form (uses the step: keyword — note that the YAML key is intentionally singular even though it groups multiple sub-steps):

steps:
  - step:
      id: enrich-customer
      steps:
        - target: http://crm/customer
        - transform: { starlang: body().customer }

Constructor: NewStep(id string, processors ...engine.Processor) *Step.

How it works:

1. Sets ex.SetProperty("HelixStepId", id).
2. Iterates the inner Processors, identical semantics to Pipeline: bail on ctx.Err(), bail on ex.IsFailed(), propagate the first error.

Common usage:

• Wrap logical blocks (fetch-data, enrich, persist) so dashboards can show timings per block.
• Nest Steps to build a hierarchy — the most recent HelixStepId wins, but distributed tracing spans nest correctly.

Pitfalls:

• The HelixStepId property is not automatically cleared after the step exits. If another Step does not overwrite it later, downstream observers will see the last-set value.
• Step does not honor HelixRouteStop — for that, use StopAwarePipeline (see eip_advanced).

Examples¶

workflows:
  - id: invoice-flow
    trigger: { uri: direct://invoices }
    steps:
      - step:
          id: validate
          steps:
            - validate: "body().amount > 0"
      - step:
          id: persist
          steps:
            - target: postgres://invoices
      - step:
          id: notify
          steps:
            - target: kafka://invoice-events

Source¶

pkg/processor/step.go

See also¶

• pipeline — anonymous sequential composition.
• eip_advanced — StopAwarePipeline, observability-aware variants.