Report data flow

One of the principal advantages of the NAV report is its built-in data flow structure. At the beginning of any report, we define DataItems (the tables) that the report will process. We can create a processing-only report that has no data items (if no looping-through database data is required), but this situation often calls for a code unit to be used. In a report, NAV automatically creates a data flow process for each DataItem, or table reference. This automatically created data flow provides specific triggers and processing events for each data item:

  • Preceding DataItem
  • After reading each record of DataItem
  • Following the end of DataItem

The underlying "black-box" report logic (the part that we can't see or affect) automatically loops through the named tables, reading and processing one record at a time. Therefore, any time, we need a process that steps through a set of data one record at a time, it is often easier to use a report object.

The reference to a database table in a report is referred to as DataItem. The report data flow structure allows us to nest data items (to create a hierarchical grandparent, parent, and child structure). If DataItem2 is nested within DataItem1 and is related to DataItem1, then for each record in DataItem1, all the related records in DataItem2 will be processed.

The following example uses tables from our WDTU system. The design is for a report to list all the scheduled instances of a Radio Show playlist grouped by Radio Show, in turn grouped by Show Type. Thus, Radio Show Type is the primary table (DataItem1). For each Radio Show Type, we want to list all Radio Shows of this type (DataItem2). Further, for each Radio Show, we want to list all the scheduled instances of the show recorded in Playlist Header (DataItem3).

Open Object Designer, select the Report object type, and click the New button. On the Report Dataset Designer screen, we first enter the table name Radio Show Type (or table number 50001), as we can see in the following screenshot. The DataItem Name, to which the C/AL code will refer, is DataItem1 in our example here. Then, we enter the second table, Radio Show, which is automatically indented relative to the data item above (the "superior" or parent data item). This indicates the nesting of the processing of the indented (child) data item within the processing of the superior data item.

For our example, we have renamed DataItems to better illustrate the report data flow. The normal behavior would be for Name in the right column to default to the table name shown in the left column (for example, Name for Radio Show would be <Radio Show> by default). This default DataItem Name would only need to be changed if the same table appeared twice within the DataItem list. If there were a second instance of Radio Show for example, we could simply name it RadioShow2 (but it would be much better to give it a name describing its purpose in context).

For each record in the parent dataitem, the indented dataitem will be fully processed, depending on the filters and the defined relationships between the superior and the indented tables. In other words, the visible indentation is only part of the necessary parent-child definition.

For our example, we enter a third table, Playlist Header, and our example name of DataItem3:

Report data flow

The following chart shows the data flow for this DataItem structure. The chart boxes are intended to show the nesting that results from the indenting of DataItems in the preceding screenshot. Radio Show DataItem is indented under Radio Show Type DataItem. This means that for every processed Radio Show Type record, all of the selected Radio Show records will be processed. That same logic applies to the Playlist Header records and Radio Show records (that is, for each Radio Show record processed, all selected Playlist records are processed):

Report data flow

The blocks visually illustrate how the data item nesting controls the data flow. As we can see, the full range of processing for DataItem2 occurs for each DataItem1 record. In turn, the full range of processing for DataItem3 occurs for each DataItem2 record.

In the NAV 2015 Role Tailored Client, report processing occurs in two separate steps, the first tied primarily to what has been designed in C/SIDE RD, the second tied to what has been designed in the SSRB. The data processing represented in the preceding image all occurs in the first step, yielding a complete dataset containing all the data that is to be rendered for the output.

Once the dataset is processed for display by the RDLC code created by the SSRB, if the output is to be displayed in NAV Client for Windows, the results are handed off to Microsoft Report Viewer. Microsoft Report Viewer provides the NAV 2015 reporting capabilities such as various types of graphics; interactive sorting and expand/collapse sections; output to PDF, Word, and Excel; and other advanced features. Other clients are served by rendering tools that address each client's capabilities and limitations.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.70.60