The functionality provided with this Technology Preview Version is intended to provide insight into future product functionality early in the process. However, this module is not yet ready for production use.
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 specificallyimportant 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.
The Reporting Feature is available via the Reporting Perspective in the Stardust Portal. Select Business Process Reporting from the Perspective Menu:

which will open the Reporting Perspective Launch Panel:

To create an (Ad hoc) Report Definition click the
![]()
icon in the menu. The Report Definition View will be opened:

Hereby, the Report Definition will be given a default name (e.g. Report Definition 1) until it is discarded or stored as a Template.
You can look at the tabs being displayed as a wizard you can step through to
However, you can step back and forth between all tabs at your convenience.
Mouse over for the Report Definition entries in the tree will show the description of the Report Definition (see below).
The first step in the definition of a Report is the data source or sources the data should be retrieved from.
Currently you can select
As the joined data may have field names colliding with internal ones - especially descriptor IDs, you can overwrite these IDs with the value of Use As. Collisions will be indicated by a highlighted field.
One of the fields of the joined external data has to be marked as the key used for the join via External Join Key. Hereby the value of that field is assumed to identify the corresponding record uniquely and will be matched with the corresponding record of internal data by using the field specified as the ... with internal Join Key.
Instead of manually specifying the record structure for the external data, you can click Load test data to obtain record structure . The Reporting Feature will use heuristics to obtain field names and types from the sample data returned by the REST call.

At report invocation time, the provided REST URL will be used to obtain all records to be joined.
The return object for the REST call is expected to be a JSON data structure, either
[{firstName: "Hanna", lastName: "Jabblonski", known: true, numberOfDependents: 3}, {firstName: "Joe", lastName: "Franklin", known: true, numberOfDependents: 0}, ...]
or
{list = [{firstName: "Hanna", lastName: "Jabblonski", known: true, numberOfDependents: 3}, {firstName: "Joe", lastName: "Franklin", known: true, numberOfDependents: 0}, ...]}
whereby the identifier for the top level object (here: list) can be an arbitrary identified.
You can add additional computed columns to the records from Audit Trail Data and externally joined data by providing a JavaScript expression to calculate corresponding data, e.g. to calculate a Name column by providing the expression
firstName + " " + lastName
or by calculating a Duration via
var from = new Data(startTimeStamp); var to = new Date(lastModificationTimeStamp); (to.getTime() - from.getTime()) / 1000 / 60 / 60; // Returns duration in hours
Note, that in the last example we even have done some variable definitions and calculations up front; only the final expression computes the value for the computed column. You can even defined functions above the return expression, e,g,
function createDurationString(from, to)
{
}
createDurationString(startTimestamp, lastModificationTimestamp)

Data retrieved from Audit Trail Data, external data sources and also computed columns can be used to create two different kinds of data sets:
Facts are the quantities you intend to investigate
Facts can be viewed as the "y-axis" of a chart.
Dimensions are quantities over which the facts (see above) will vary.
E.g. an (average) process duration may vary over

Selecting Switch to Start Date and End Date will allow you to enter start and end dates

For other selections of the first dimension, select boxes

or
will be displayed.




The charts displayed depend on the types of fact and dimensions you have selected.Pie Charts are only offered for discrete dimensions.

Wherever applicable for a chart type, X and Y axis settings can be configured.

For XY Plots, Bar Charts and Candlestick Charts settings for displaying the series values can be configured.

The Document Layout allows you to create a complete HTML document which may serve as a dashboard in a corporate portal.
You can either edit the HTML document in WYSIWYG (What you see is what you get) mode or (by clicking the source code icon) in HTML source code.
If the Data Set is specified as a Record Set, The Document Layout has access to the entire record set as an Angular JS Controller object. This way you can use HTML5 syntax in the HTML source code of the document HTML markup, e.g. by defining
<h1>Customers</h1>
<ul ng-repeat="record in recordSet">
<li>{{record.FirstName}} {{record.LastName}}</li>
</ul>
The Document Layout also allows you embed Report Definitions you have already defined by dragging and dropping these from the Reporting Launch Panel into the Layout Tab, but not to the HTML Editor.
Combining HTML5 and embedding, you can e.g. display series of charts parameterized by criteria you use HTML5 for iteration, e.g.
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.
Wherever a input in the Stardust Reporting is succeeded by the
![]()
icon, clicking this icon would mark the corresponding quantity or setting as a parameter. In turn the
![]()
removes it from the parameter list.
Parameters have IDs to be used for report execution via URI. These IDs will be displayed whenever you hover over the icons above.


Pie Charts will be rendered as follows:

Note, that you cannot use the "/" character for report names.








For convenience the Scheduling tab displays the next execution based on previous settings for a Scheduled Report Template.

After defining a report and saving this Report Definition for repetetive use, you may may invoke reports based on that Report Definition via a URI interface, to embed the report with your web pages.
http://host:port/contextRoot/plugins/bpm-reporting/views/reportPanel.html?path=reportPath¶meter_parameterId1=parameterValue1¶meter_parameterId2=parameterValue2 ...
Hereby
A few examples:
The URI
http://localhost:9090/server/plugins/bpm-reporting/views/reportPanel.html?path=/reports/Process%20Instances%20over%20Time.bpmrpt
executes and retrieves the public Report Definition Process Instances over Time.
The URI
executes and retrieves the personal Report Definition Processes in State mm..
All Audit Trail Data are accessed via the Reporting Feature are accessed through the same interfaces used for programming (e.g. QueryService) or the Portal (Workflow Execution Perspective, Business Control Center). Hence, the access rights defined via process modeling and additional declaratiove security will apply.