IFS Report Designer Layout Development¶
This section of the Open Development Guide deals with updating, modifying or developing report layouts for operational reports in IFS Cloud using the IFS Report Designer tool. This guide does not cover the data assembly step. For a guide to the entire report development flow, including the modeling and data assembly steps as well, please refer to the full report development guide (available to customers that has bought the full development license from IFS).
Concepts¶
There 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 types¶
There 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 the 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).
Structure¶
The 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 are able to do in the layout. Whether or not it's possible to iterate over a collection of elements, where you are 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, sir name 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 sir/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 two types of pages in the tool, first and rest. 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. In the 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 are designing a simple list report the flow section might just contain one table with a couple of columns. What you are 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 layouts¶
This 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 Configuration¶
This 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
Additional information¶
Provides additional information that will be useful during the report development cycle. Covers varied aspects, such as good practices that are best adopted as a developer, step-by-step guides to complex report activities, links to external reference material and troubleshooting tips to help resolve problems faced during report development.