Freshmark replication server

freshmark-canonical

Markdown document

Rebuild Plan

rebuild-plan.md

Rebuild Plan

Immediate goals

  1. Keep a clean, canonical inventory of the replication server
  2. Map which schemas and tables drive reports, menus, and selectors
  3. Surface that map in a local UI so we can browse it quickly
  4. Capture enough logic to rebuild menus and report flows in a modern frontend
  5. Move from report preview to a usable report runner

Current approach

1. Snapshot first

Use a read-only snapshot step to pull current metadata into data/snapshot.json.

This gives us:

  • a stable review artifact
  • something we can diff over time
  • a source for the local UI when live credentials are not set

2. Drill into representative screens

Good starting programs:

  • ZZMENU_MAN
  • ZZENQ
  • DEBTOR_MAN
  • ABSA_BUYER_MAN
  • ACTIVE_CS_BUYERS

Why these:

  • they cover menus, reports, maintenance screens, selectors, and embedded runtime logic

3. Trace menu execution paths

For each sample menu row in ZM_MENU, we need to determine:

  • what ZM_TYPE means
  • whether ZM_PGM maps directly to a report key, a screen key, or a wrapper action
  • how ZM_PGMBEFORE and ZM_PGMAFTER are used
  • how ZM_ZC intersects with ZC_SEC_GROUP

4. Trace report execution paths

For each sample report definition in ZE_ENQ, we need to determine:

  • how the frontend selects a report
  • where runtime parameters are gathered
  • how selector definitions in ZS_SEL are injected into the flow
  • which ZP_PGMS or menu items launch the report

5. Build the report-runner phase

The simulator now proves that we can:

  • resolve a menu row to a report key
  • load ZE_ENQ
  • build preview SQL
  • query the replicated data schema

The next step is to turn that into a structured report runner with prompt handling, query planning, and better execution fidelity.

See report-runner-phase for the detailed roadmap and Mermaid diagrams.

Concrete next tasks

  1. Extend the UI with search by menu group and security code
  2. Add a route that compares ZM_MENU.ZM_PGM against ZP_PGMS.ZP_PROGRAM and ZE_ENQ.ZE_KEY
  3. Decode a few ZX_CODE token families: - $SELECT - $CALCULATE - $VALIDATE - F: - S: - O:
  4. Build a cross-reference document for: - menu item -> program - menu item -> report - program -> selectors - report -> base tables
  5. Add a query-plan layer between ZE_ENQ metadata and live SQL execution
  6. Support ZE_ORDER in the preview and runner compiler
  7. Document three representative report-launch chains end to end