Add a value to your own operational report

R · Report / 26R1 reference / Documentation-based walkthrough draft

Add an external handover reference to a customer-owned operational report, carry it through the generated XML, and display it in an IFS Report Designer layout. The example result is a PDF containing DEMO-HO-014 once at header level and the report’s existing detail rows below it.

This procedure has not been generated or executed in IFS. It uses the XML/XSD/RDL Report Designer route. Report Studio uses a different layout/data workflow.

Before you start

Use a nonproduction development environment with a compatible Developer Studio build home, database connection, IFS Report Designer, and permission to maintain report definitions/layouts and execute the report. Server-connected Report Designer also needs its configured IAM client.

Start with an existing, working customer-owned report and retain a baseline PDF, parameters, source model, and layout. This walkthrough extends that report; it does not supply a complete report project. Do not convert a Core RDF into a supposed CoreReport-Cust.rdf override. For a Core report, investigate supported report configuration or a separately owned report first.

Download the target worksheet, synthetic SQL, and acceptance checks. CDemoHandover is a fictional alias: record your actual report identity and component before editing.

1. Trace the report and its generation mode

1. Open the working report’s .report model in Developer Studio and find its header and detail blocks.
2. Locate the .rdf implementation, generated .xsd, sample XML, and currently deployed .rdl layout.
3. Inspect the model’s GenerateRdf property. This walkthrough’s main path uses Yes, where the model supplies the query and generation supplies the RDF. Do not switch an existing manually implemented report to generated mode merely to follow the example.
4. Record the report ID and active layout from Report Definition Overview and its detail page. Export the existing layout/schema for comparison.
5. Identify the block representing one report header. A header reference belongs there, not in each detail row.

.report model and queries
  → .rdf data assembly
  → executed XML matching generated .xsd
  → .rdl field binding
  → registered layout and PDF

Adding a field to a page or OData projection does not add it to report data.

2. Prove the example value in SQL

In an approved development SQL session, run the downloadable fixture. It contains this read-only query:

SELECT CAST('DEMO-HO-014' AS VARCHAR2(50)) c_external_reference
FROM dual;

Expect one row and the exact value DEMO-HO-014. This proves only the fixture expression; it does not test report generation or access.

For a disposable demonstration report, use this expression as the new column of the existing header query. Preserve every existing column, join, filter, parameter, and correlation. Do not replace a business report’s header query with the one-row fixture.

For the real requirement, replace the constant with the actual value from an approved secured source, retaining the alias c_external_reference. Verify that the query still returns the intended number of headers. An added join that multiplies rows is a data defect even if the PDF looks plausible.

3. Add the attribute in the report model

1. Open the header block’s query in the report model/diagram editor.
2. Add the expression from step 2 to its SELECT list with the explicit alias.
3. Choose Apply. In the documented model editor, applying SQL adds attributes/parameters derived from the query.
4. Inspect the resulting attribute and set or confirm Text with length 50. Check that the generated name corresponds to the query alias.
5. If your existing model requires an explicit attribute definition, use the block’s Add Attribute command and map it to the same query result. Avoid creating both an inferred attribute and a duplicate manual attribute.
6. Save the model and inspect changes to the block and its existing attributes.

For an XML-based model, the intended attribute has this shape. This is a fragment, not an importable report:

<ATTRIBUTE>
  <NAME>CExternalReference</NAME>
  <DATATYPE>TEXT</DATATYPE>
  <LENGTH>50</LENGTH>
</ATTRIBUTE>

If your report is manually implemented, maintain its own data-fetch and result-storage implementation instead. An XML writer call can add the element at the correct nesting level:

Xml_Record_Writer_SYS.Add_Element(
   xml_,
   'C_EXTERNAL_REFERENCE',
   rec_.c_external_reference);

Here xml_ and rec_ represent the actual variables in that report. This call alone is not a complete RDF implementation and does not populate a separate result table. Preserve the report’s existing assembly pattern.

4. Regenerate, deploy, and inspect real report data

1. Save/generate with the matching toolchain. For a fully generated report, inspect the regenerated RDF, schema, and sample data; do not hand-patch the generated RDF.
2. Search the XSD for the new attribute and record its exact element path. Inspect its parent block and cardinality.
3. Deploy the RDF through your development process before using the report from Report Designer. Install the matching schema with the report’s delivery artifacts.
4. Execute the report in IFS with the baseline parameters and obtain its XML through the environment’s supported report-data/export tooling.
5. Find DEMO-HO-014 in that executed XML. Confirm one header value and the same detail count as the baseline.

The illustrative XML download shows a header with two detail rows. It is an original teaching fixture, not generated IFS output. Do not load it against an unrelated generated XSD and expect compatibility. Use your report’s generated sample or executed XML for the actual layout preview.

Checkpoint: actual report XML contains the value in the intended block. Resolve missing or duplicated data before editing the layout.

5. Bind the value in Report Designer

1. Open IFS Report Designer. Use the File menu to open a copy of the customer-owned .rdl layout.
2. If connected, confirm that the schema comes from the intended environment/report. If disconnected, select the newly generated local XSD when prompted. Check for missing-field entries in the schema tree’s Errors folder.
3. Expand the header block in the upper-left schema tree and locate the actual new element from step 4.
4. Drag the field into the layout’s existing header area at the appropriate master level. Do not drag a detail field into a higher-level header; the designer cannot determine which detail row should supply it.
5. Add a static label, “External handover reference”, beside the field. Select the field/container and adjust width and wrapping in the property panel so a 50-character reference remains readable.
6. Preserve the existing detail table in the flow area. Tables repeat their data rows; a static header should not be implemented as an extra detail row.
7. Save the layout under the customer-owned layout name and retain its relationship to the report ID.
8. Select File → Preview, choose the matching executed/sample XML, and inspect the PDF.

Checkpoint: the reference appears once in the intended header position, the detail rows remain intact, and no text overlaps or clips.

6. Register and test the delivered layout

1. In IFS Cloud, open Report Definition Overview, find the actual report ID, and open its detail page.
2. Check the registered XML schema. Use the supported schema import if the delivered version is outdated.
3. Add/select the customer-owned layout entry and use its Import Layout action to import the saved .rdl. Server-connected Report Designer also provides a deployment command; use the delivery method established for your project.
4. Confirm that the layout is active, correctly titled, and associated with the intended report. Select it explicitly for the first test rather than assuming it became the default.
5. Execute the report as the intended report user with the baseline parameters. Compare the generated PDF, executed XML, and source-record values.
6. Deliver the model, generated artifacts, schema, layout, registration, and required report permissions together through the normal build/install process. Repeat the same checks in the target test environment.

7. Run the acceptance cases

Case	Expected result
Short reference	Exact value appears once at the correct level
Empty optional reference	Report still renders; no literal null text
50-character ASCII reference	Full value remains readable without clipping
Multiple detail rows	Row count and existing totals match the baseline
Enough detail rows for several pages	Headers, footers, and repeated table headings remain correct
Intended report user	Can execute only the reports and data their role permits
Different registered layout	Confirms which version is actually selected at runtime

Use the 50-character value from the configuration example. Record actual PDF/XML evidence in the acceptance worksheet. A designer preview does not establish runtime permissions or deployed-layout selection.

Troubleshooting

Symptom	Check and correction
Element absent from XSD	Inspect query alias, Apply result, model block, and generation output
In XSD but absent from executed XML	Check deployed RDF, data query, parameters, and assembly mode
In XML but blank in PDF	Compare field binding, schema version, and selected registered layout
Reference repeats for every line	Move the binding to the intended master/header level
Extra business rows	Correct the data query/join; hiding rows in the layout does not repair the data
New layout looks like the old one	Select the new active layout explicitly and verify its imported version

Exercise and solution

Exercise: preview both an empty reference and a maximum-length reference without changing the business query. Identify whether either case requires a layout change.

Show the solution

Copy the generated sample XML twice, preserving its namespace, root, and required fields. Use the schema’s permitted representation for an absent value in one copy and the 50-character ASCII reference in the other. Preview both against the same layout. Adjust the field width/wrapping if necessary and confirm that the empty case still renders cleanly. These fixture previews complement, but do not replace, a real report execution.

Cleanup and verification status

Deactivate the training layout or restore the previous customer-owned layout. Restore the previous model through the normal build process if the exercise is being removed. Keep report evidence required by your team; do not delete shared report results or change global data-assembly settings for this exercise.

Status: documentation-based 26R1 walkthrough. IFS generation, Oracle execution, layout preview, deployment, and role checks remain unverified until performed in a compatible environment.

Sources

• Working with Reports
• Report diagram editing and SQL Apply
• Data assembly
• Creating and modifying layouts
• Report Designer controls and preview
• Report definitions and layout registration
• Development overview and customization limits