This article is intended for developers extending or using Graphical Scheduler as a library with the intent of leveraging as much configuration as possible that Graphical Scheduler provides, but using custom Gantt rendering.

The intend is to document how to use the Graphical Scheduler API to retrieve JSON for custom rendering, avoiding using the Graphical Scheduler UI within Business Central to render, to allow customizations or rendering tools outside of Business Central.

This article presumes an existing basic knowledge of views, datasources, configuration, and basic working knowledge of Graphical Scheduler.

A general description of the concepts involved is available in this YouTube video: https://www.youtube.com/watch?v=h8HOJRaVk7k&list=PLxMITbffo0eHuzLuNr7o96E2if4BY19qw.

To get the JSON directly you can use codeunit 70097928 “IWX Scheduler Controller”.

Use GetWorkMachineResourceTree( precView: Record “IWX Scheduler View” ) to retrieve Json for the working tree structure (the left hand side of the Gantt chart, typically describing information about ‘Where’ something is, most typically for production order routing information this is a tree structure showing work centers and machine centers.

Use GetAvailableStyles(codViewName: Code[60]) to get a JSON structure of the available styles (color coding).

Use GetViewDataAsJson(pcodView: Code[60]; peTimeScale: Enum “IWX Scheduler Time Scale Enum”; pdtStart: DateTime; pdtEnd: DateTime) or GetViewDataAsJson(pcodView: Code[60]; pcodPreset: Code[20]) to supply a view and get a full dataset of all of the cell data needed to render a Gantt chart.

The view data contains all field data for the view, datasources, and individual datasource configuration.  This article will only document the key details needed to allow custom rendering. A developer should inspect the JSON to see access to other data supplied within the JSON.  A developer will notice that some fields appear to duplicate information, and those additional fields are there for legacy support, upgrades, and other historical purposes.

"view" will contain high level information about the view itself.

Key attributes of “view” will be:

• “No.”, the view code.
• “Description”, the description
• “Default_Date_Preset_Code”, the default date preset code.

“datasources” will contain an array of elements, where each element is a configured datasource.  A datasource could represent actual data or dynamically generated data relevant to the time scale.

Key attributes of a datasource array element will be:

• “No”, the view code.
• “Code”, the datasource for the view code.
• “Tooltip_Template”, the html tooltip template.
• “Cell_Template”, the html cell template. Square brackets with the field name will be used to reference field data specific to a cell being rendered.  When a valid field is supplied in the cell template or tooltip template, then they will appear in the “Data_Fields” csv array referenced below.  This information combined can be used to fill in the cell block or the tooltip block.
• “State”, “Enabled” if it’s enabled.
• “Data_Codeunit”, the codeunit that generates the cell data.  This would only be needed if collecting the data yourself.
• “Data_Fields”, a string containing a comma separated list of field names that are data fields needed for the tooltip or the cell templates. This can be used to help optimize which data you want to cache.
• “Filter”, this is used by the data codeunit to help filter the data.  The data collected will already be filtered.
• “Update_Mode” will indicate whether the datasource is read-only, or whether it’s configured to allow writes (effectively whether you can drag and drop a cell or not).

“data” contains an array of data where each array for each datasource, which contains a further array of the cell data relevant to that datasource.

Within a “data” array element, there will be a “total” attribute depicting the total rows (cells) for that specific datasource, “primaryKey” containing an array of what the primary key fields are, “readonly” representing whether it’s readonly or write-able, “datasource” representing a reference to the datasource code, and “items” representing an array of the cell data.

With an “items” cell data array the important item cell data will be:

• “key”, representing a unique key for the data.  This is defined by the data codeunit that generates the data, and by convention (but not rule) it is typically the record id when the data is a result of data persisted in a Business Central table.  This is not the same as a unique cell identifier.
• “tableno”, the table it came from.  This typically is the same as the tableno defined on the datasource, however a custom data codeunit can collect multiple data from multiple different sources.
• “UniqueCellIdentifier” used to represent a unique key for the cell.  This is used in the rendering widget within Business Central to help connect cells.
• “Context_Key_1”, typically the document no. of the row being rendered, in the case of a production order routing line this would be the production order no, but is ultimately up to the data codeunit that collects the data.
• “Context_Key_2”, typically a secondary key reference. In the case of production order routing line this would often be the production order line no.
• “Context_Key_3”, a tertiary key reference. In the case of a production order routing line, this would typically be the operation no.  Context key 1,2,3 are used to help the Business Central rendering widget identify related cells to draw arrows between.
• “Starting_Date_Time”, the starting date time of the cell, in ISO8601 formatted datetime.
• “Ending_Date_Time”, the ending date time of the cell, in ISO8601 formatted datetime.
• “DurationMs”, an integer for the duration of the cell.
• “Duration”, a human friendly description of the duration of the cell.
• “Style”, a reference to the style configuration, can be used for color coding.
• “Work_Center_Row_Identifier”: a reference to where on the tree this should appear (the vertical layout, often a work/machine center, but could represent things such as the resource, or however the scheduler view is configured).
• “Data_Fields”, a csv list of the actual data for the cell row that maps to the same ordinal position of the columns identified in “Data_Fields” in the datasource configuration.   This can be used to dynamically generate the cell contents when applied with the cell template, or the tooltip template.
• “Next_Key_3”, a helper guide for the rendering widget to know what next cell to help link, presuming context keys 1 and 2 are the same. In a production order routing line this would represent the next operation no.
• “Previous_Key_3”, a helper guide for the rendering widget to know what next cell to help link, presuming context keys 1 and 2 are the same. In a production order routing line this would represent the previous operation no.

Important note: the cell data will also often contain a Json representation of the entire record, you will notice that this can cause some field to be repeated when the field of the record has the same information as a field.

Example JSON for a call to GetViewDataAsJson (with a lot of data removed and only probable important fields for customizations identified).