Salesforce converter drops OSI metrics during export

[saurabhdeshp]

i reproduced this on main at 1f367e35.

When exporting an OSI model to Salesforce using toSF, the converter generates objects and fields but skips the entire metrics[] section. It exits successfully without producing semanticCalculatedMeasurements.

This affects anyone relying on OSI metric definitions to create Salesforce semantic models, regardless of the source platform.

Example

A model declares a numeric orders.amount field and this metric:

metrics:
  - name: total_sales
    expression:
      dialects:
        - dialect: TABLEAU
          expression: SUM([orders].[amount])

The numeric field is exported, but total_sales is missing from the output. Using a TABLEAU expression does not resolve the issue.

The forward path in MetricMappingHandler explicitly skips metric mapping. The README documents this limitation, but successful conversion can still leave downstream automation with an incomplete model.

Proposed behavior

• Export supported OSI metrics as semanticCalculatedMeasurements, preserving names, descriptions, expressions and types.
• Resolve expressions against the model’s semantic fields.
• Fail with an actionable error when a metric cannot be converted, rather than silently omitting it.
• Add tests that verify metric preservation and resolved references, beyond JSON-schema validation.

Expression handling should align with the existing work in #222 and discussion #28.

Is anyone already working on this? i’d like to align on the scope before contributing an implementation.

[Ashfaqbs]

Not aware of anyone working on it -- I'd like to take this, if that's alright.

Confirmed the mechanism: MetricMappingHandler.mapOssieToSalesforce() (converters/salesforce/.../MetricMappingHandler.java:71-84) strips the metric-prefixed mappings and returns without writing anything to outputData" -- a deliberate stub, per the log line. The reverse direction, mapSalesforceToOssie()/wrapExpressions()(same file, :89-159), is fully implemented: it maps name/description/datatype and unwraps the Ossieexpression.dialects[]structure down to a flat string, picking theTABLEAU`-dialect entry.

Proposed scope, split in two so the first piece is deliverable now without blocking on the second:

1. This issue: a symmetric unwrapExpressions() for the OSSIE→SF direction -- map name/description/datatype (reusing SalesforceDataTypeMapper), and pick the TABLEAU-dialect expression out of dialects[] into semanticCalculatedMeasurements[].expression, mirroring the existing wrap/unwrap symmetry already in the file. A metric with no TABLEAU dialect entry (or no expression at all) fails the conversion with an actionable error naming the metric, rather than being silently dropped -- covers the "fail rather than omit" part of the proposed behavior.
2. Follow-up, not in this PR: "resolve expressions against the model's semantic fields" -- validating/rewriting the expression body itself. Adds a SqlGlot implementation of the OSI SQL dialect #222 is the actual expression-language engine for this (ossie_sql, SqlGlot-based), but it's Python and this converter is Java, and Adds a SqlGlot implementation of the OSI SQL dialect #222 is still open/unmerged. I don't think semantic field resolution belongs in this fix until Adds a SqlGlot implementation of the OSI SQL dialect #222 lands and there's a cross-language story for using it from the Java converter -- happy to be corrected if that's wrong.

Tests would extend OssieToSalesforceConverterTest alongside the existing coverage, verifying metric preservation, expression unwrapping, and the new failure path for an unconvertible metric.

Let me know if this scope (or the split) is off before I start.

[saurabhdeshp]

thanks @Ashfaqbs for picking this up. i’ve opened a follow-up issue #403 for expression translation and build on #402. i’ll also carry over the field-reference validation requested in this issue, since #402 leaves that for follow-up work. i’ll link the issues so that requirement stays tracked.

[saurabhdeshp]

The field-reference validation requested here is now implemented in draft PR #404, tracked under #403 and built on #402. Metric export and the extension-preservation fixes remain in #402.