Task: Export a pricing engine configuration as ORE XML

The document is the one ORE reads, at Examples/ORE-API/Input/pricingengine.xml in the ORE source:

<?xml version="1.0"?>
<PricingEngines>
  <Product type="Swap">
    <Model>DiscountedCashflows</Model>
    <ModelParameters/>
    <Engine>DiscountingSwapEngine</Engine>
    <EngineParameters/>
  </Product>
  <GlobalParameters>
    <Parameter name="ContinueOnCalibrationError">true</Parameter>
  </GlobalParameters>
</PricingEngines>

The products come first, in their stored position. Each carries Model, ModelParameters, Engine and EngineParameters in that order, and an empty section is a self-closing element. The global parameters are one GlobalParameters block after the products. A parameter is <Parameter name"…">value</Parameter>=, the value escaped, and a section's parameters follow their stored position. The model and engine are the pair the configuration holds; a product with neither cannot be exported.

The analytics service owns the document, so the operation lives beside the save: a export_pricing_engines_document_request carrying the configuration id, and a response carrying either the XML text or the reason it was refused. One handler reads the configuration, its products and its parameters, checks the party, and writes the document with pugixml, so the escaping and the self-closing sections are the library's and not string concatenation. It refuses an id the party cannot see and an id that does not exist, and it names the reason in the reply.

The BFF adds GET /api/reporting/pricing-engines/:id/export, which asks the service and answers application/xml with a Content-Disposition: attachment whose filename is the configuration's name. The screen's Export button calls it; the button is not a client-side generator, because the XML is the service's answer and ORE's format is not the screen's to own.

ores.shell gets pricing_engines export <id> [--file <path>]. It sends the same request and writes the text to the file, or to standard output when no file is named, so a person can pipe it into ORE. Its test asserts the text, the refusal of an unknown id, and the file written.

• A golden test exports a seeded configuration and compares the document with the XML ORE reads for the same configuration, structure and values, with attribute order stated by the test rather than by the writer.
• A round-trip test parses the export with pugixml and asserts every product, model, engine and parameter against the stored rows.
• A refusal test asserts the message for an id that does not exist and for one the party cannot see.
• The shell test asserts the command's text and its file.

1. The analytics request, handler and writer, with the golden and round-trip tests at the service.
2. The BFF route, with a test that the content type and the filename are the configuration's.
3. The screen button, checked in the browser with Playwright by downloading the file.
4. The shell command and its test.

The export is read-only: it writes no row and records no history.

The review of this task found the document stated twice: the exporter wrote it with pugixml and pricing_engine_projection::write wrote it with the schema-driven emitter, and the two already disagreed on an empty GlobalParameters. RS-ORE-04 names one ORE exporter, so the export became the only writer:

• exporter::export_pricing_engines has one pugixml body, and two entry points: the ORE domain document (the type pricing_engine_projection::reverse answers with and write takes) and the analytics messaging document, which regroups the rows and calls the first.
• pricing_engine_projection::write delegates to the domain entry point, and the emitter call it used is gone. Read, map and reverse are untouched, so xg::pricing_engines_document stays where the row mapping needs it.

The consolidation changed what the run import writes back: a configuration whose source names no GlobalParameters block now leaves the store with an empty one, because the writer states every section. ORE reads it, and the only difference is that block. Two tests state it rather than hide it:

• every_pricing_engine_document_in_the_corpus_round_trips accepts exactly one difference, GlobalParameters was added at the document, and pins the count: 70 of the 125 corpus documents gain the block, the other 55 round trip byte for byte as structure.
• a run's configuration imports and exports as the same files accepts only a difference that ends in : GlobalParameters was added.

Committed on feature/export-a-pricing-engine-configuration-as-ore-xml in eight commits:

• ./compass.sh build passes.
• The ORE core suite passes (401 cases, 475592 assertions), as does the analytics core suite (76 cases), the shell reporting suite (571 cases), the reporting api suite (68 cases), the BFF suite (1005 tests), the web suite (2067 tests) and the wire protocol suite (225 tests). ores.ore.service.tests holds no cases: the service's units are covered by the core suite and by the run below.
• GET /api/reporting/pricing-engines/5979e68e-ad30-fb47-b828-e7b08398f43d/ore-document answered 200, content-type: application/xml, content-disposition: attachment; filename"pricingengine.xml", for the HK party's *XVA Overnight* configuration. The document is well formed under =xmllint --noout and holds the five products in their stored positions (Swap 0, CrossCurrencySwap 1, FxForward 2, CreditDefaultSwap 3, Bond 4), their models, engines and parameters, and one GlobalParameters block holding ContinueOnCalibrationError.
• The web package's tests hold no browser: the screens render to static markup there, so the button, its permission and the dialog's sentence are asserted on the rendered page, and the download request is asserted against a stubbed fetch in api/pricingEngines.test.ts. The click itself was not driven through a browser.
• After the consolidation the route and the command were run again and their documents are byte identical to the ones above, because this configuration holds a global parameter. The consolidation's own change is the other case: 70 of the 125 corpus documents gained an empty GlobalParameters, and the round-trip cases state it.
• pricing_engines export <id> --file <path> wrote the same document, byte for byte, after account_operations switch-party to the HK party of the ACME Corporation tenant. The name came from ores_reporting_file_types_tbl (row setup.pricingEnginesFile, configuration type pricing_engines, kind input_document, direction input, name pattern pricingengine.xml).

python3 build/scripts/local_checks.py --exclude-heavy runs 63 checks and passes 61. The two that fail carry main's inputs, not this branch's: prototypes names a market data prototype index main does not list, and er-diagram warns about ores_refdata_convention_kind_terms_tbl, a table this branch does not touch. The branch changes no create or drop SQL and no prototype file, which git diff against main confirms.

The branch also carries the XML benchmark row the repo asks for when XML code changes (benchmarks/xml/history.tsv, 96 rows recorded), and it formats one market data file main already carried unformatted, because the web check refuses the whole tree otherwise.

The component model now states the pugixml dependency the exporter needs, so the generated build file is no longer hand-edited; component-drift and cmake-sources both pass.