Report Example

This example shows how a report artifact fits into a BDL document.

It demonstrates report identity and artifact composition without inventing undocumented query, data-source, column, filter, or rendering structures.

Example

{
  "schema": "barsa.definition.v1",
  "project": {
    "code": "SAMPLE",
    "caption": "Sample",
    "systemId": "${RESOLVE_SYSTEM_ID}",
    "version": "1.0.0"
  },
  "references": {},
  "artifacts": [
    {
      "kind": "report",
      "code": "CustomerList",
      "caption": "Customer List"
    }
  ]
}

What this example demonstrates

• Reports are first-class BDL artifacts.
• A report has its own stable authoring identity.
• Human-readable caption and machine-oriented code remain separate.
• Report definitions belong in the root artifacts collection.

Data source and query structure

A real report normally needs a data source and may require:

• Source entity or view
• Query or selection logic
• Columns
• Filters
• Sorting
• Parameters
• Grouping or aggregation
• Permissions

The exact shape of these elements must come from the active BDL baseline.

Do not infer undocumented report syntax from this minimal example.

Existing metadata

When a report refers to existing Barsa entities, fields, views, or other objects, resolve them from authoritative live metadata.

Do not fabricate internal identifiers or assume field names from captions.

Capability checks

Before generating a report, verify:

1. Native Barsa supports the intended reporting capability.
2. Runtime support exists for the report behavior.
3. BDL can express the required report structure.
4. The current authoring surface allows that report definition to be generated.

Safe authoring pattern

Start with report identity and the smallest supported data definition.

Add filters, columns, parameters, and presentation details incrementally.

Validate each meaningful step and prefer diagnostics over guessed metadata.

Next

The next example introduces a workflow artifact.