Analytics widget not loading in embedded cost management dashboard

We’re facing a critical issue where our embedded analytics widget in the cost management dashboard won’t load at all in ENOVIA R2020x. This is blocking budget review processes as managers can’t see the cost trend visualizations they need for approval decisions.

The widget area just shows a spinning loader indefinitely, then eventually displays “Widget failed to load” after about 2 minutes. This started happening after we upgraded from R2019x last month. Other dashboard widgets load fine - it’s specifically the analytics widget that’s failing. The browser console shows a JavaScript error but I’m not sure how to interpret it:

Uncaught TypeError: Cannot read property 'chartConfig' of undefined
  at AnalyticsWidget.initialize (analytics-widget.js:247)
  at DashboardLoader.loadWidget (dashboard.js:892)

I’ve verified that users have proper permissions to view cost data, and the underlying data queries return results when run manually. The widget initialization seems to be the problem, but I’m not sure if this is a JavaScript error that needs debugging or a dashboard version compatibility issue with R2020x.

I’ve resolved this exact widget initialization failure multiple times during R2020x upgrades. The solution requires addressing all three key areas:

Widget Initialization Fix: The R2020x analytics widget requires explicit initialization with the new API. Update your dashboard HTML to include proper widget registration:

var widget = new AnalyticsWidget({
  containerId: 'cost-analytics-container',
  config: { chartType: 'trend', dataSource: 'cost-mgmt' }
});
widget.initialize();

The key change from R2019x is that chartConfig is now nested under a config object. Your old code was passing chartConfig directly to the constructor which is no longer supported.

JavaScript Error Debugging: The “Cannot read property ‘chartConfig’ of undefined” error occurs because the widget configuration isn’t loading before initialization. Add defensive checks:

if (typeof widgetConfig !== 'undefined' && widgetConfig.chartConfig) {
  widget.setChartConfig(widgetConfig.chartConfig);
} else {
  console.error('Widget config not loaded');
}

Enable debug mode in your dashboard to see detailed initialization logs: Add ?debug=true to the dashboard URL and check console for configuration loading sequence.

Dashboard Version Compatibility: R2020x introduced breaking changes in the analytics widget framework. You need to migrate your widget configuration to the new schema:

  1. Copy analyticsWidgetConfig.json to analyticsWidgetConfig_v2020.json
  2. Update the JSON structure for R2020x compatibility:
    • Move chartConfig properties under a “config” parent object
    • Change “dataSource” to “dataSourceConfig” with explicit connection parameters
    • Update “renderOptions” to “displayOptions” with new property names
  3. Update dashboard reference to use the new config file
  4. Test in isolated dashboard instance before deploying to production

Pseudocode for config migration:


// Pseudocode - Widget config migration steps:
1. Load existing R2019x widget configuration JSON
2. Create new R2020x config structure with nested objects
3. Map old property names to new schema:
   - chartConfig -> config.chart
   - dataSource -> config.dataSourceConfig.endpoint
   - renderOptions -> displayOptions
4. Validate new config against R2020x widget schema
5. Deploy updated config with version suffix
6. Update dashboard to reference new config file
// See: R2020x Analytics Widget Migration Guide Section 3.4

Critical compatibility note: R2020x widgets require jQuery 3.5+ and Chart.js 3.x. Verify your dashboard includes these library versions. Incompatible library versions cause silent initialization failures.

After implementing these fixes, clear browser cache completely and test with browser dev tools network tab open to verify the configuration file loads successfully. The widget should initialize within 2-3 seconds. If you still see the spinner, check the server logs for widget resource loading errors - sometimes file permissions or path issues prevent config files from being served properly after upgrade.


This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

That error indicates the widget is trying to access a configuration object that doesn’t exist. Check if the analytics widget configuration file is present in the dashboard resources. After upgrade, custom widget configs sometimes don’t migrate properly. Look for analyticsWidgetConfig.json in your dashboard configuration directory.

R2020x changed the analytics widget API significantly. If your dashboard was customized in R2019x, the widget initialization code is likely incompatible. The chartConfig property was moved to a nested configuration object in R2020x. You’ll need to update the widget initialization parameters to match the new API structure. Check the R2020x migration guide for analytics widget breaking changes.

I found the analyticsWidgetConfig.json file and it looks like it’s still using the R2019x format. Should I just update the JSON structure manually or is there a migration utility? Also concerned about breaking other dashboards if I modify shared widget configurations.

Don’t modify shared configs manually - you’ll break other dashboards. Create a new widget configuration specific to cost management that uses R2020x format. The migration utility only handles core system widgets, not custom analytics widgets. You need to version your widget config files separately per dashboard instance to avoid conflicts during upgrades. This is a known gap in the upgrade tooling for custom dashboard components.

For the immediate JavaScript error, add null checking before accessing chartConfig. Wrap the initialization in a try-catch block to get better error details. The undefined property suggests the config isn’t loading at all, not just wrong format. Check browser network tab to see if analyticsWidgetConfig.json is actually being fetched - might be a 404 or permission issue preventing the file from loading.