Lofty idea: reproduce a dashboard outside of Sugar

Hi Francesca Shiekh ,

If you’re planning to use a live data report (which may not actually be necessary based on your ask here), you would need to interpret the JSON results and render them using the ChartJS engine (there's no shortcuts on this).

Another option is to leverage the existing “Download chart” functionality in the report dashlet. This is a client-side trigger that outputs a base64-encoded PNG of the chart currently being displayed. In theory, you could use that output to download the image and save to your external service and serve it. That said, this approach would unfortunately require a manual step.

Elaborating, on the previous alternative with a more auto approach, you could extend
clients/base/views/report-dashlet/report-dashlet.js
by adding a listener for the report:data:chart:loaded event and triggering the downloadReport function. This would generate the base64 PNG automatically, which you could then capture, send to an API, store, and make available to other users later.

The main advantage of this approach is that you’d get the full chart exactly as rendered in Sugar. The downside is that the dashboard would need to remain open, since the dashlet would effectively be “publishing” the image every X minutes or hours.

Let me know if you want to explore any of these options in more detail.

Thanks for the tips Rafael Fernandes 

We have tools in Wolfram Language to create charts of all sorts.

The idea is to run the APIs from a Wolfram Notebook, retrieve the data, and build the charts in Wolfram Language.

I'm 99% of the way there, I'm missing a few labels... I was just hoping to find more guidance for building the interpreter of the dashboard and chart metadata to translate it into Wolfram Language, ideally the code would be generic enough that I could pass any dashboardID and reproduce its current state on demand inside Wolfram Language presentations.

All in the spirit of "drink your own Prosecco" (I'm Italian no Champagne)

This might be of further help...

The manner in which we render the reports based charts can be described as follows...

- Reports object is instantiated and report definition is retrieved (stored as JSON object in saved_reports->content)  

- Reports object executes run_query() to retrieve its corresponding data

- Data is used to then create a JSON object whose format matches that expected by the chart (it will vary based on chart type, etc.), the JSON typically also includes some of the settings for the chart attributes Rafael mentions

- JSON object is passed to chart object and the chart is then rendered  

I would think you should be able to mimic this behavior by retrieving the report definition (to get the report labels, etc) then retrieving the data via run_query(). It sounds like the Wolfram engine you mention would have a predefined format it expects for the input, so you would then just need to massage the result set a bit to map it accordingly. 

This might be of further help...

The manner in which we render the reports based charts can be described as follows...

- Reports object is instantiated and report definition is retrieved (stored as JSON object in saved_reports->content)  

- Reports object executes run_query() to retrieve its corresponding data

- Data is used to then create a JSON object whose format matches that expected by the chart (it will vary based on chart type, etc.), the JSON typically also includes some of the settings for the chart attributes Rafael mentions

- JSON object is passed to chart object and the chart is then rendered  

I would think you should be able to mimic this behavior by retrieving the report definition (to get the report labels, etc) then retrieving the data via run_query(). It sounds like the Wolfram engine you mention would have a predefined format it expects for the input, so you would then just need to massage the result set a bit to map it accordingly.