Skip to main content
RELAMPO
Documentation
ENES

Compatibility

Not all Relampo YAML files are created the same way. This page explains the practical differences between handwritten YAML and YAML generated or modified by Relampo tooling.

Main YAML sources​

In normal usage, a Relampo YAML file may come from:

  • manual authoring
  • relampo record
  • relampo correlate --apply
  • relampo convert

All of them aim to produce a valid Relampo scenario file, but they do not start from the same level of completeness.

Handwritten YAML​

A handwritten YAML file is typically:

  • cleaner and more intentional
  • organized around business meaning
  • easier to review in version control
  • better suited for long-term maintenance

However, it may initially lack:

  • realistic captured payload details
  • extractor definitions
  • correlation placeholders

Recorder-generated YAML​

A YAML file generated by record is usually the fastest way to bootstrap a script.

Typical characteristics:

  • derived from captured traffic
  • includes concrete request sequence
  • may contain raw values that later need normalization
  • often needs cleanup before it becomes maintainable

Use recorder output as a starting artifact, not always as a final long-term script.

Correlated YAML​

After running relampo correlate --apply, the YAML may include:

  • extractor definitions
  • {{variable}} placeholders replacing hard-coded values
  • transformed request sections that make the flow reusable

This is expected and desirable. A correlated file is still the same scenario definition, but now it is more stable across repeated runs.

Converted YAML​

A YAML file generated by convert (for example, from another source format) is typically:

  • structurally valid
  • useful as a migration baseline
  • likely to need review and normalization

Converted output should be treated like imported source material: validate it, inspect it, and refine it before treating it as canonical.

What should remain stable across all forms​

Regardless of how the file was created, the following expectations should hold:

  • the file must remain valid YAML
  • the scenario structure should remain readable and maintainable
  • request ordering should reflect the intended flow
  • interpolation placeholders should remain explicit and reviewable

What may differ​

Depending on the source, these areas may vary:

  • naming quality
  • level of normalization
  • presence or absence of extractors
  • whether payloads are raw or cleaned up
  • how much metadata is already present

Editing guidance by source​

If the file came from record​

  • normalize names
  • remove obvious noise
  • validate the flow structure
  • apply correlation where needed

If the file came from correlate --apply​

  • keep extractor and placeholder changes unless intentionally revising them
  • review generated variable names for readability
  • validate after additional manual edits

If the file came from convert​

  • inspect for structural correctness
  • verify headers and payload assumptions
  • confirm that the imported model maps correctly to Relampo semantics

A generated file becomes production-grade only after:

  1. it is reviewed
  2. it is validated
  3. its reusable values are intentional
  4. it is stored and maintained like a real test asset