Fixed positions can be specified either by numerical indexes or by MDX tuple names.
The syntax is similar to the MDX syntax, except that all the member names need to be
enclosed in brackets. If a tuple is composed of only one member, then the tuple name
would be something like
while for tuples composed of multiple members, the name would be something of the
([Store].[All Stores].[USA].[CA],[Customers].[All Customers].[USA].
The names are matched against
A data mapping yields the cell value if the data label is
and yields the cell’s
formatted value if the label is
Following are some data mapping examples:
: Yields the cell value corresponding to the current axis positions; all the result
axes will be iterated in this case.
: Yields the cell value corresponding to the
member on the
axis and the current
position on the
axis; only the
axis will be iterated in this case.
: Yields the formatted cell value at the
level on the
axis (and corresponding to the
member on the
: Yields the
cell value for the
level on the
axis and the
axis; both the
axis will be iterated.
The Mondrian data source performs a Cartesian iteration on the entries of axes that do
not have fixed positions. If axis positions are not specified, then all the axes are iterated.
For example, if the data mappings specify positions that look like
[?, ?, x]
, then the
axis entries will be iterated by first going through the
and then going through the
entries for each of them.
The most common case is to iterate on only one axis. In this case, the conversion from
the OLAP result to a JasperReports data source is more natural.
At an iteration step, a data source row is produced only if the maximum level of member
mappings for each axis/dimension is reached by the current axis members. If the
maximum level is not reached for an axis/dimension, then the matching mapping values
are collected and the axis iterations continue without producing a data source row. The
reason behind this logic is that the higher levels of OLAP dimensions conceptually
correspond to JasperReports groups, not data source rows. Values found at the higher
levels can be mapped to report fields using level specifications and member-level filters,
and can be used in the report group headers or footers.
For example, suppose the data source iterates on the following entries on the
[Store].[All Stores].[USA].[CA].[Los Angeles]
[Store].[All Stores].[USA].[CA].[San Francisco]
Presuming that the maximum level of the member mappings is
, the first two entries of the axis would not produce a data source row, as the
maximum level is not reached. Member or data values can be mapped for the country or
state levels and used in group headers/footers or in the detail band.
Mapping Syntax Reference
Table 8-2 can be used as a reference for the field mapping syntax.
Member_mapping | Cell_mapping
A field mapping is either a member
mapping or cell mapping.
A member mapping consists of a
member specification and an optional
Axis Axis_position [Level]
A member specification consists of an
axis, an axis position, and an optional
Axis_no | Axis_name
An axis is either specified by index or
"Axis(" <number> ")"
An axis is specified by number.
"Columns" | "Rows" | "Pages"
| "Chapters" | "Sections"
An axis is specified by name.
Axis_position "[" (<number> | <name>) "]"
An axis position is specified by either an
index of the axis tuple or a dimension
"[" (<number> | <name>) "]"
A level is specified either by a depth or
by a level name.
"(" <name> ")"
A property is specified by name.
A cell mapping consists of a data
specification, an optional member filter,
and optional axis indexes.
C# PDF - Extract Text from Scanned PDF Using OCR SDK
C#.NET PDF - Extract Text from Scanned PDF Using OCR SDK for C#.NET. How to Extract Text from Adobe PDF Document Using .NET OCR Library in Visual C#. Overview. extract text from pdf file; get text from pdf into excel
"Data" | "FormattedData"
A data specification can point to either
the actual cell value or the cell’s
Member_filter "(" Member ("," Member)* ")"
A member filter consists of one or more
member specifications, separated by
Axis_ indexes "(" Axis_index (","
Axis indexes are separated by comma.
Note that the number of indexes must be
the same as the number of query axes.
"?" | <number> | Axis_tuple |
An axis index is either the question
mark character(?, meaning all axes), a
number, an axis tuple, or an axis
"(" Axis_member (","
An axis tuple consists of a list of axis
members, separated by commas.
"[" <name> "]" (".[" + <name>
An axis member is an MDX member
having all the names enclosed in
Table 8-2. Field Mapping Syntax
You can see a working example of the MDX query executer in the supplied
sample, which is part of the project distribution source
MDX queries can also be executed on remote OLAP data sources via the XML for
Analysis interface. This functionality is implemented in JasperReports as a query
Just like the Mondrian query executer presented in the previous section, the XMLA
query executer is also mapped by default to the
query languages, but the
Mondrian query executer takes precedence.
The dispatch between the two query executers that are mapped on the same query
language is done by a special query executer implementation. It is actually the
class that is registered by default with the
query languages, and it delegates the creation of the query instances at runtime to either
depending on the specific parameter values that are passed in at report-filling time.
It first checks for the
and if found, the Mondrian query executer takes over. If this parameter is not found, it
then checks for the
to see if
the XMLA query executer can be used.
The XMLA query executer defines three connection parameters, as shown in Table 8-3.
The XMLA/SOAP service URL
The information required to connect to the OLAP
The name of the OLAP catalog to use
Table 8-3. XMLA Connection Parameters
The parameter names can be referred to in Java code using constants from the
The XMLA query executer creates a data source equivalent to the one created by the
Mondrian query executer explained in the previous chapter, with a few minor exceptions.
This means that the result cube traversal and field mapping logic described in the
previous “MDX Query Executer” section of this chapter applies for the XMLA query
executer as well.
The XMLA query executer lacks some of the functionality of the Mondrian query
executer, due to inherent limitations of the XML for Analysis standard. The missing
features are the following:
Mapping report fields to custom member properties: The Mondrian data source
allows field mappings like
Rows[Store][Store Name](Store Manager)
which yields the
property of the
level of the
dimension. This mapping doesn’t require an explicit mention of the property in the
MDX query; the user only needs to select the member and can access all its
But this does not work with XMLA; therefore, a query that could be used to retrieve
custom member properties when using a Mondrian data source will not be able to do so
when executed through XMLA.
A workaround would be to use calculated members, like in the following query:
with member [Measures].[Store Manager]
as [Store].[Store Name].CurrentMember.Properties("Store Manager")
select [Measures].[Store Manager] on columns ...
Mapping report fields to
instances: If a report field
member mapping doesn’t specify a dimension level (for example,
then the Mondrian data source yields the
field value. The report designer would use this object to retrieve additional member
information that is not accessible via other mapping conventions.
For XMLA, it is not possible to produce a complete
hence this feature is not supported.
Parent member matching: Using the Mondrian query executer, if a result axis
contains, for instance, only members on the
level of the
dimension, you can still map fields to members on the
is a parent of the
level). This is implemented using the
This does not work via XMLA since the parent member information is not present in the
response. The workaround is to make sure that required parent members get selected on
the result axis.
EJB QL/JPA Q
The EJB QL report query executer adds support for reporting on EJB 3.0 persistent
entities data. For an EJB QL query in a report, the query executer will use the EJB 3.0
Java Persistence API to execute the query against an entity manager provided at runtime,
and use the query result as a data source for the report.
The built-in EJB QL query executer is registered by default for queries having
as their language. This mapping can be changed by using JasperReports
properties (see the “Query Executer API” section, earlier in this chapter).
The EJB QL query executer contributes built-in parameters to the report:
The entity manager to be used for executing the query
An optional query hints map
When the report template contains an EJB QL query, you must provide a JPA entity
manager at runtime; the query executer will run the query using the supplied entity
manager. The entity manager is of type
should be provided via the
Map parameters = new HashMap();
javax.persistence.EntityManager entityManager =
The means of getting hold of an entity manager depends on the particular EJB/JPA
environment and implementation.
An additional parameter named
allows you to specify query
hints for running the query. The parameter value should be a map containing hint values
mapped to hint names. The hints are set using the
javax.persistence.Query.setHint(String hintName, Object value)
Hints can also be specified statically by using report properties. The query executer treats
any report property starting with
as a hint by interpreting
the property suffix as the hint name and the property value as the hint value. Thus, if the
following property is present in the report:
as value will be set when running the query.
Note that only hints that accept
values can be set using this mechanism.
A separate report property can be used to paginate the query result. This property can be
used for controlling the amount of Java heap space used by the query executer while
filling the report. The property can be set in the following manner:
The results of the query will be fetched in chunks containing 500 rows.
The pagination is achieved via the
methods. Obviously, using pagination could result in
performance loss. Therefore enabling it is primarily recommended when the query
results are very large.
EJB QL report queries can contain parameters of any type. At runtime, the value of the
parameter is directly set by using
javax.persistence.Query.setParameter(String name, Object value)
no other processing.
The result of the query execution is sent to a data source implementation, which iterates
over it and extracts report field values. Fields are mapped to specific values in the query
result by specifying the mapping as field description or field name.
The JPA data source can handle two types of query results:
Queries returning a single entity/bean per row
Queries returning object tuples as rows
When the query returns a single entity/bean per row, as in
SELECT m FROM Movie m
SELECT NEW MovieDescription(m.title, m.gender) FROM Movie m
then the field mappings are interpreted as bean property names.
The same conventions as for JavaBeans data sources are used (see “JavaBeans Data
Sources” section earlier in this chapter).
When the query returns multiple objects per row, as in
SELECT m.title, m.gender FROM Movie m
then the fields are mapped using one of the following forms:
: Maps the field to a value specified by its position in the
resulting tuple. The positions start from 1.
: Maps the field to a property of a value specified
by its position in the resulting tuple.
For instance, the following mappings could be used for a query returning multiple
objects per row:
The EJB QL query executer and the corresponding JPA data source are used in the
sample supplied as part of the JasperReports distribution
The report fields represent the only way to map data from the data source into the report
template and to use this data in report expressions to obtain the desired output. Listing 8-
3 gives the JRXML syntax for report field declarations.
When declaring report fields, make sure that the data source you supply at report-filling
time can provide values for all those fields.
For example, if you use the
the report’s SQL query is used, make sure that there is a column for each field in the
result set obtained after the execution of the query. The corresponding column must bear
the same name and have the same data type as the field that maps it.
Listing 8-3. JRXML Syntax
<!ELEMENT field (property*, fieldDescription?)>
name CDATA #REQUIRED
class CDATA "java.lang.String"
<!ELEMENT fieldDescription (#PCDATA)>
Following is a small example that shows the fields to declare to map the columns of a
database table, called
, that has the structure shown in Table 8-4.
Table 8-4. Employees Table Structure
The report fields should declare the field as follows:
<field name="EmployeeID" class="java.lang.Integer"/>
<field name="LastName" class="java.lang.String"/>
<field name="FirstName" class="java.lang.String"/>
<field name="HireDate" class="java.util.Date"/>
If you declare a field without a corresponding column in the result set, an exception will
be thrown at runtime. The columns in the result set produced by the execution of the
SQL query that do not have corresponding fields in the report template will not affect the
report-filling operations, but they also won’t be accessible for display on the report.
The following subsections describe the components of a report field definition.
attribute of the
element is mandatory. It lets you reference the field
in report expressions by name.
The second attribute for a report field specifies the class name for the field values. Its
default value is
, but it can be changed to any class available at
runtime. Regardless of the type of a report field, the engine makes the appropriate cast in
report expressions in which the
token is used, making manual casts unnecessary.
This additional text chunk can prove very useful when implementing a custom data
source, for example. You could store in it a key, or whatever information you might need
in order to retrieve the field’s value from the custom data source at runtime.
By using the optional
element instead of the field name, you can
easily overcome restrictions of field-naming conventions when retrieving the field values
from the data source.
<field name="PersonName" class="java.lang.String"
The field description is less important than in previous versions of the library because
now even the field’s name accepts dots, spaces, and other special characters.
Just like the report template and report parameters, report fields can have custom-defined
properties, too. This comes in addition to the field description, which can be considered a
built-in report field property. Custom properties are useful in some cases where more
information or meta data needs to be associated with the report field definition. This
additional information can be leveraged by query executer or data source
JasperReports supports in-memory field-based data source sorting. This functionality can
be used, for instance, when data sorting is required and the data source implementation
does not support it (as in the case of the CSV data source).
The sorting is activated by the presence of one or more
elements in the
report template. When at least one sort field is specified for the report, the original report
data source (either passed directly or provided by a query executer) is passed to a
instance that fetches all the records from it, performs an in-
memory sort according to the specified fields, and replaces the original data source in the
The JRXML syntax for
elements is given in Listing 8-4.
Listing 8-4. JRXML Syntax
<!ELEMENT sortField EMPTY>
name CDATA #REQUIRED
order (Ascending | Descending) "Ascending"
The sort field name should coincide with a report field name. Fields used for sorting
should have types that implement
. Sorting will be performed
using the natural order for all fields except those of type
, for which
a collator corresponding to the report fill locale is used.
When several sort fields are specified, the sorting will be performed using the fields as
sort keys in the order in which they appear in the report template.
Check the supplied
sample to see how in-memory
data source sorting could be used.
Report variables are special objects built on top of a report expression. They can simplify
the report template by isolating in one place an expression that is heavily used
throughout the report template, and they can perform various calculations based on the
Listing 8-5 gives the JRXML syntax for report variables.
Listing 8-5. JRXML Syntax
<!ELEMENT variable (variableExpression?, initialValueExpression?)>
name CDATA #REQUIRED
class CDATA "java.lang.String"
resetType (None | Report | Page | Column | Group) "Report"
resetGroup CDATA #IMPLIED
incrementType (None | Report | Page | Column | Group) "None"
incrementGroup CDATA #IMPLIED
calculation (Nothing | Count | DistinctCount | Sum | Average |
| Highest | StandardDeviation | Variance | System | First)
incrementerFactoryClass CDATA #IMPLIED
<!ELEMENT variableExpression (#PCDATA)>
Documents you may be interested
Documents you may be interested