Requests for new reports come from every department and in many different forms. Most of the time, users have an idea in mind of how they would like the data to be shown.

Nevertheless, a report developer should always keep in mind some important points. Everything is related to data:

• Retrieval: A good report developer should have a good knowledge of the business process (how data is created, modified, and deleted) and data topology (where data is stored). Data can be retrieved from heterogenous resources that cannot be directly stored in Dynamics 365 Business Central tables. As an example, you might want to run an HTTP call to a web service to gather some data outside the database and store it in a physical or temporary table before processing it.
• Processing: Some of the data that's presented could be the result of data aggregation, could be calculated from different fields, or could even be the results from a concatenation of values from different tables. The result of data retrieval and processing generates the dataset.
• Presentation: Datasets are sent from the application to the Report Viewer component, which takes care of data rendering and presentation. Together with the dataset, a report definition file (Report.rdlc) is sent to the Report Viewer to build up the content of the report. The report definition file contains the metadata structure and rules to render the report. Despite its extension (.rdlc), this is actually an XML-formatted flat file. Tools such as the Report Builder or Visual Studio can digest the XML file and create a presentation of the report structure in a more human-readable way. Every action that's taken in this designer has the consequence of editing and changing the XML file.

With Dynamics 365 Business Central, it is also possible to design reports to perform only data retrieval and processing, typically committing changes in tables as a result of the process. No data is presented to the users, hence no layout is needed, and no dataset will be created.

Reports can be grouped into two main categories: processing only and dataset-based.

Reports that are processing only do not have any layout. They also typically do not have any columns defined in the dataset and are only used to process data. Quite often, the same result could be achieved using codeunit objects instead since these are just simple code repositories and do not have any graphical or User Interface (UI) interaction. To give you a simple example, you could create a processing-only report with a data item that loops all the customer records and prints a flat JSON file with the customer number, name, and email. The same could be achieved by implementing a codeunit with a function that declares an IF CustomerRec FINDSET THEN REPEAT UNTIL NEXT=0 loop. Within this loop, it is possible to write a flat JSON file with exactly the same information.

The pros and cons of using a processing-only report or a codeunit have been tabulated here:

A report object has the following tree structure:

• Request Page:
  • Columns:
    • Groups:
      • Fields
  • Actions
• Dataset:
  • Data items:
    • Properties
    • Triggers
    • Columns:
      • Properties
      • Triggers
  • Labels:
    • Properties
  • Layout:
    • RDL
    • Word

After installing the standard AL Language extension and CRS AL Language extension tool, we could use a treport or treport (CRS) snippet to create a prototype of a report and inspect all the different items related to the main content areas: the dataset and the request page. Layouts are just references to the corresponding output (an RDL and/or Word file) within the report objects, and these are created with tools other than Visual Studio Code. We will work with them later in this chapter.

After exploring the anatomy of a report object in AL, it is time to see the tools that are used in Word and RDL layouts.