IFS Report Designer Development (for ifs app8)

admin

IFS Report Designer DevelopmentIntroductionThe IFS Report Designer tool is used to create RDL Layouts, which is basically in XML format and well formatted. RDL objects in the layout is used to create a XSLT style sheet when previewing the report. Then these XSLT style sheets apply to a XML document and results in a XSL-FO (Formatting Objects XSL) document.
The idea behind the tool is to make it easy to create layouts for operational reports (business documents), things like invoices, order confirmations and so on. It wasn't designed to cover every aspect of  XSL-FO, nor does it claim to be a general XSLT to XSL-FO design tool. In it's current shape and form the tool is not intended for development of ad-hoc or analytic reports (typically including business graphics such as pie charts, bar charts and so on). For that kind of reports please refer to the IFS documentation for Quick Reports, Crystal Reports and Crystal Analysis.
Development of operational reports within IFS involves a number of different tasks, all of them very tightly connected to how the operation reporting process within IFS works.

The data assembly step/process gathers the operational data that makes up this particular report instance. The RDL objects in the RDL layout created using the IFS Report Designer tool is used to generate XSL style sheet during the report generation process Then the assembled data is formatted using the XSL objects. The formatted output (XSL-FO) can be rendered using a Formatting Object processor (like FOP from Apache). The rendered output is typically a PDF file that can be used both for preview and to make a print out.
When developing a report, one needs to

• Define the data structure and write the code for the data assembly      process.
• Create the layout used in the formatting step.
• Register and configure the system to use this newly developed/modified      report and/or layout.
  

This developers guide is divided into the above logical sections. Where the layout creation/modification and configuration is something that can be done by customers while the data assembly step is something that most likely would involve IFS staff.
ConceptsThere are a couple of basic concepts that are used during the development as well as modification of a report and its layouts. It's important to understand these basic concepts before getting started developing a report or if any major structural changes are going to be made to an existing report.
File typesThere are a couple of different data/file types involved. The XML is the actual report data, this is generated by the business logic layer (the RDF, PL/SQL code). XML schemas (in our case XSD files) provide a means for defining the structure, content and semantics of XML documents. This means a schema can be used to validate that a XML document has the correct structure content and semantics. The schema is generated from the modeled report structure. The schema contains all the information needed to create the layout such as structure, data types, length of attributes and so on.
The XML schema is the input to the Report Designer designer tool. The output is an RDL layout in XML format. The RDL layout objects converted into XSL objects and used to transform a XML document. The generated XSL layout is applied to the XML and in our case the output is another XML document, namely a XSL-FO (Formatting Object) document. The XSL-FO document can be rendered to a PDF document (Portable Document Format created/defined by Adobe).
StructureThe structure of the data (the XML) and the structure of the layout is very tightly connected. What this means is that the structure of the data very much determines what you're able to do in the layout. Whether or not it's possible to iterate over a collection of elements, where you're able to put elements in the layout and so on. Due to this it's important to consider the graphical representation when designing the logical structure of the data to be used in the report/layout. It could very well be that two layouts are substantially different and that results in designing this as two separate reports rather than two different layouts for the same report.
It's not possible to alter/change the grouping of the data in the layout. It's still possible to ignore groups, but you can't change the grouping. The following example illustrates what can be done and not. Let's say we have a phone book type of report/data. We have a number of entries consisting of a first name, surname and a phone number. Let's also say that these numbers are grouped by region. From this type of data it's very simple to create a layout that lists all entries per region. We can choose to sort the entries either by surname/first name or number. We can also skip the region grouping and just list all entries independent of region. What's significantly harder on the other hand is to create a layout that groups the phone book entries by name and list region and number for each entry. Using custom XSLT expressions it's close to anything is possible, but not recommended.
Considering this it's extremely important to consider the layout of the report when the structure of the data is defined.
XML is a hierarchic data format, this is reflected by a tables concept in the layout design tool. Connecting a table to a certain node in the schema/XML will result in a loop/iteration. A table object in the tools is used to design how one row in the data. A table can also have a header and a footer part that will not be repeated for all rows, but occurs once (or on every page if applicable). Each child element of the XML node to which the table is linked will result in the designed output once you render it. The other building block is an object called a block container or simply a block. Blocks can be used to logically group content in the layout, for easier editing.
There are three types of pages in the tool, first, rest and last. Each page can consist of three sections, header footer and flow. There is no need to use all page types nor page sections if not necessary to achieve the desired layout. The page type first makes it possible to design specific layouts for the  first page. All other pages will get rest layout. If there is a last page in the layout, it may consist of either static header or different header and footer.  In each header and footer section of a page you put static content, page header and footers. The layout of a header and footer is fixed, theses sections will not expand as the flow section. In the header and footer it's wysiwyg (what you see is what you get). In the flow section, where tables are inserted, things will expand depending on the amount of data. If you're designing a simple list report the flow section might just contain one table with a couple of columns. What you're designing is the content of one row in the list report. In design mode you will only see one row. Once the report is run or previewed with data containing multiple rows you will see that the row you designed will be repeated for every row in the data set.
Creating and Modifying layoutsThis section of the developers guide, which by far is the largest section, covers a number of aspects regarding designing, changing and modifying an IFS Report Designer layout. Layout development/modification is something that can be done both by customers and IFS staff and this is why this part of the guide is aimed at both customers doing layout development/modification as well as IFS staff that develops reports from scratch..
Read more in Creating and Modifying  Layouts - Details
Deployment and ConfigurationThis section is also covered in the administrator guide, but some parts of  special interest to a developer is described here as well. We're focusing on  being able to deploy, configure and test the newly developed or modified report.  Things that are highlighted are:

• Configure XML generation
• Registering the layout
• Setting up company logotypes
  

Read more in Deployment and  Configuration - Details