We’re experiencing issues filtering simulation data through the SAP PLM OData API when using numeric field conditions. Our BI reporting pipeline relies on filtering by temperature and pressure values, but queries consistently return empty results even though data exists.
The filter syntax we’re using:
/SimulationDataSet?$filter=Temperature gt 150.5
/SimulationDataSet?$filter=Pressure eq 2.5
Both queries return zero records, but querying without filters shows thousands of records with values matching our criteria. String field filters work perfectly. We’re on SAP PLM 2022 FP03. Has anyone encountered similar OData filter behavior with numeric simulation fields? This is breaking our automated BI reporting workflows.
I’ve dealt with this extensively across multiple SAP PLM 2022 implementations. Your issue stems from three interconnected problems:
OData Filter Syntax & Numeric Types:
SAP PLM’s OData implementation for simulation data uses a legacy type mapping system. Numeric simulation fields are often stored as NUMC or CURR database types, but the OData service layer doesn’t properly expose them as Edm.Decimal. Try this corrected syntax:
/SimulationDataSet?$filter=Temperature gt 150.5M
/SimulationDataSet?$filter=Pressure eq 2.5M
The ‘M’ suffix forces decimal literal interpretation.
Known SAP PLM OData Issues:
SAP Note 3156789 documents this exact behavior in SAP PLM 2022 FP01-FP03. The simulation data OData service has a defect where numeric comparison operators fail silently when field metadata doesn’t explicitly declare Edm.Decimal with precision/scale attributes. You need to either:
- Apply SAP PLM 2022 FP04 (includes fix)
- Implement OSS Note 3156789 manually
- Modify your OData service definition to include explicit type declarations
Numeric Field Data Types - Permanent Solution:
Navigate to transaction SEGW (Service Gateway Builder) and locate your simulation data service. For each numeric field:
- Open property definition
- Set Type = Edm.Decimal
- Define Precision = 15, Scale = 5
- Regenerate service classes
- Re-register OData service
Alternative approach if you can’t modify the service:
// Use function imports for complex filtering
GET /SimulationDataFunction?MinTemp=150.5&MaxTemp=200.0
This creates a custom function import that handles numeric filtering in ABAP backend where type conversion is reliable. For your BI reporting pipeline, I’d recommend implementing the function import approach immediately while planning the FP04 upgrade. The function import bypasses the OData filter translation layer entirely and gives you full control over numeric comparisons in ABAP code.
Also verify your simulation data model configuration (transaction SPRO → PLM → Simulation Data Management → Define Numeric Field Properties) ensures all temperature and pressure attributes are explicitly typed as numeric with appropriate precision. This prevents future issues when adding new simulation parameters.
We encountered this exact issue last year. The problem was SAP PLM 2022’s OData implementation has a known bug with decimal comparison operators on simulation data fields. SAP released a patch in FP04 that addresses numeric filter handling. Before upgrading, we worked around it by using range filters with ge/le operators instead of direct eq/gt comparisons. Also ensure your OData service registration includes proper type mappings for all numeric simulation attributes.
Have you checked the OData trace logs? Enable detailed logging in your SAP PLM system (transaction SICF, activate logging for your OData service endpoint). The trace will show you exactly how the filter is being translated to the underlying database query. I suspect the numeric values aren’t being properly cast in the SQL generation layer, which is a known issue with certain SAP PLM OData service implementations for simulation data.
This is definitely related to how SAP PLM exposes simulation numeric fields through OData. The simulation data management module uses a generic attribute storage mechanism where numeric values can be stored with different precision levels. When the OData service generates metadata, it sometimes defaults to string representation for fields with variable precision. Check your simulation data model configuration and ensure numeric fields have explicit type definitions rather than relying on auto-detection.