FPM Chart UIBB: A Data-Model Driven Approach

In Floorplan Manager, charting is done on the basis of a data-model driven approach.

In the data-model driven approach (see following figure), the application developer first chooses (in the feeder class) the table model on which the chart is to be configured during design time and rendered during the runtime. A simple table model is provided that can be addressed by DDIC table types for example, and that can be efficiently consumed by the application. Later, a chart type is selected that fits the data provided.

The data model is defined in the GET_DEFINITION method of the feeder class.

Figure 1: Data-Model Driven Approach in FPM Charting

With this approach, the application developer is never forced to invest in techniques close to the rendering (JSON or Java Script). Instead, he or she stays focused on the back-end application logic, and the corresponding data retrieval from arbitrary data sources (classic DDIC, In-Memory, Cloud, SOA, ODATA, and so on).

On configuration level (dynamic or static) dimensions and measures are defined on the basis of the given data model. A dimension is regarded in this context as a range (for example, City, Country, Month, Year and Currency Code), whereas a measure is understood as something that can be quantified by numbers only. A measure can be always used as a dimension; a dimension cannot however also be converted always into a measure.

Charting takes place on the basis of one table, where single columns (table fields) are defined either as a Dimension or as a Measure. Most of the DDIC table types can be regarded as a table model. The table model is naturally similar to the data model of the List ATS UIBB.

The data-model driven approach allows for the generation of several chart types on one dataset. For instance, a dataset that is visualized using a Bar Chart can be also rendered as an Area or Line Chart. Restricting to one Measure, the same dataset can be rendered as a Pie Chart or Donut Chart, and so on. For more information, see Chart Types: Minimum Requirements.

For the application developer, the Table Model is an excellent candidate that should be exposed by the FPM APIs, since it can be easily prepared from most of the DDIC table types, as the following code shows:

DATA: lt_table TYPE <<DDIC_TABLE_TYPE>>,
              lo_table_descr TYPE REF TO cl_abap_tabledescr.
              lo_table_descr ?= cl_abap_tabledescr=>describe_by_data( lt_table ).