Report Definitions describe from which data sources the report data are to be retrieved, how these data should be presented and how the Report Definition might be used repetitively.
Report Definitions can be parameterized e.g. to run a report for a timeframe starting from a varying date or by filtering the report by varying data. Report Parameters are specifically important for the use of Report Definitions as Report Templates.
The easiest way of using a Reporting Definition is to retrieve the result for one off-use.
If you intend to use the Report Definitions more often, possibly with some parameterization you can store Report Definitions as Report Templates for use by yourself or for use by a specific user group. Report Templates can also be used for retrieval of the result via URL invocation, which allows you to embed report results e.g. in a company portal.
You may configure repetitive execution of a Report Definition and delivery of the result either into the document repository or via e-mail. Refer to chapter Scheduling Reports for details on how to schedule your report definition in the Reporting perspective.
The Reporting Feature is available via the Reporting Perspective in the Stardust Portal. Select Reporting from the Navigation toolbar:

which will open the Reporting Perspective Launch Panel:

The root folders for the report definitions have the following structure:

Please refer to section How Report Definitions are stored of chapter Storing Report Definitions for details on the different storage types of report definitions.
Usually, the execution of a report requires parameterization
The Stardust Reporting allows you to specify various settings for a Report Definition as parameters and set these parameters for a concrete execution of this Report Definition.
Parameters have IDs to be used for report execution via URI. These IDs will be displayed whenever you hover over the icons above.
Reports using a large amount of data might cause issues like OutOfMemoryErrors. It is recommended to:
Around 700 MB of heap size per 1 million activity instance objects and 1 GB heap size per 1 million process instance objects are required in the filter result set that contributes to a report. This could be via cumulation or direct rendering into a table. Please note that these numbers are only rough estimate and the exact memory usage can vary based on details like descriptor usage or other model specifics.
All Audit Trail Data accessed via the Reporting Feature are accessed through
the same interfaces used for programming (e.g. QueryService) or the
Portal (Workflow Execution Perspective, Control Center). Hence, the
access rights defined via process modeling and additional declarative security
will apply.