Sample bundle smoke test

Table of Contents

This page defines one report: Sample bundle smoke test. It takes an ORE example bundle that already exists, submits it to the compute grid, and records where the engine's output landed. It proves that a report definition, a report instance and the workflow that carries them work end to end, and it deliberately analyses nothing. It runs on demand, against a database built from nothing, and it is the first report to run after the grid is provisioned.

1. Purpose

Proves the report machinery, not a risk number. A green run says the definition was read, the instance walked its states, the workflow dispatched its steps in the configured order, the grid executed the job, and the output came back to storage. Nothing downstream of that is checked here, because the value of the report is that a failure of any of those can be attributed without a domain calculation in the way.

The decision it feeds is whether to look at any other report yet. While this report is red, every other report's failure is ambiguous.

2. Audience

Role What it takes from the report
engineer A single run that isolates the report and compute machinery from the risk analytics.
release check A reproduction that starts from a recreated database, so a pass is repeatable.

3. Frequency

Cycle intraday (whenever an engineer asks for it), frequency on-demand. It is not scheduled and belongs to no batch. It is the report the smoke test of a freshly provisioned environment triggers by hand.

Field Value
Cycle intraday
Frequency on-demand
Batch none
Owner reporting

4. Inputs

  • A prepared input archive, named by the definition's prepared_input_key. The run selects pre-processing substitute, so it gathers no trades and no market data and assembles no bundle. The archive the repository ships is external/ore/packages/TA002_IR_Swap.tar.gz, the Input/ directory of the Academy's TA002_IR_Swap example: one 20Y EUR fixed-versus-float interest rate swap.
  • The engine package the grid runs. The repository ships ORE 1.8.17.0 for the x64-linux triplet; the app version and its platform row are seeded, and the bytes are uploaded to storage per the compute runbook.
  • A compute app version visible to the tenant the definition runs in.
  • The input archive must already be in storage when the run starts. With pre-processing substituted, nothing in the run uploads it.

5. Outputs

The engine's Output/ directory, archived per result in storage at the result's output URI, holding npv.csv, flows.csv and curves.csv. The repository also holds the Academy example's reference output at external/ore/examples/Academy/TA002_IR_Swap/ExpectedOutput/, from which the engine packages were verified.

The report rows are the report instance's own record: its state walk and the output location. Nothing parses the CSVs, because the report asks no question of them.

6. Measures

None. This report computes no measure and carries no Greek set; it exists to exercise the pipeline. A run of it that produces the three CSV artefacts and a completed instance has succeeded.

7. ORE configuration

The run document is the one inside the prepared archive, submitted verbatim. Nothing in the report authors or rewrites it, which is the point of the substitute: the run's input is exactly what a person would hand the engine.

<Analytics>
  <Analytic type="npv">
    <Parameter name="active">Y</Parameter>
    <Parameter name="baseCurrency">EUR</Parameter>
    <Parameter name="outputFileName">npv.csv</Parameter>
  </Analytic>
  <Analytic type="cashflow">
    <Parameter name="active">Y</Parameter>
    <Parameter name="outputFileName">flows.csv</Parameter>
  </Analytic>
  <Analytic type="curves">
    <Parameter name="active">Y</Parameter>
    <Parameter name="configuration">default</Parameter>
    <Parameter name="grid">240,1M</Parameter>
    <Parameter name="outputFileName">curves.csv</Parameter>
  </Analytic>
</Analytics>

8. Parameters

The definition states the rows below and nothing else. Every other parameter a production report would carry is irrelevant, because the run pre-processes nothing and post-processes nothing.

Parameter Domain Default Meaning
pre_processing substitute substitute Resolve a prepared archive instead of generating input.
prepared_input_key a storage object path none The archive the run submits.
post_processing ignore ignore Record that the engine produced output; ingest nothing.

9. Test coverage

This report is the test coverage. It substitutes pre-processing and ignores post-processing, so the chain it runs is four steps rather than seven: resolve_prepared_input, submit_compute, ignore_compute_results, finalise. What it deliberately does not cover is the two substituted phases and the parsing of engine results.

The story that owns it is Run an example bundle through the compute grid from a report definition; the analysis behind it is What a no-preprocessing report run requires.

10. Related

11. See also

Emacs 29.3 (Org mode 9.6.15)