Parameters in EMF and UML data sets

You can define parameters in EMF and UML data sets, use them in data set queries for row mapping and column mapping, and bind values to them in the report design. You can use parameters to create variations in generic data sets, and so avoid creating multiple data sets that are nearly identical to each other.. You can also use parameters to join objects.

How to use parameters to create variations in generic data sets

You can use parameters when you need several data sets that are identical except for a slight variation. To avoid creating multiple data sets, you can create a single data set that uses a parameter to represent the variation, and bind the parameter to the changed value.

For example, instead of having one data set that gets all classes in packages named A and another that gets all classes in packages named B, you can create one data set that gets all classes in packages named $name. You can then bind $name to A and B. This makes your data sets more concise and more reusable.

For additional information about using parameters and about binding values to them, see the Field Guide to BIRT.

How to use parameters to join objects

You can use parameters to join objects in data sets when you design reports for EMF and UML models. Depending on the relationship between objects, you can use a key to join the objects; when you cannot use a key, you can define a parameter to join the objects. However, you can also use parameters when a key would work.

Objects that you can join without parameters

You do not need to create parameters to join objects in the following situations:

Objects that require parameters when you join them

You need parameters to join objects in the following situations:
  • Relationships that have 1–to* multiplicity, where the end with a multiplicity of 1 is not navigable
    " "
  • Relationships that have *-to-* multiplicity
    “ "

Parameters are necessary in these situations because EMF and UML data sets do not support columns with multiplicity greater than 1. This fact means that you cannot represent a navigable end with a multiplicity of * by using a column in a data set that represents the other end of the relationship. These types of relationships are very common in EMF and UML models.

Tips for joining objects

You can use parameters in a data set to join two objects that are related by any type of relationship in the model. To use parameters to join objects, you define a data set that represents a navigable end of a relationship, and define for it a parameter that represents the object at the other end of the relationship. Then, in the row-mapping query, you use this parameter as a context to navigate from it to the objects that represent the rows of the data set.

For example, in a data set that represents class Y, you can define a parameter $X that represents an object of class X, and then specify its row-mapping query as the XPath expression $X\y. This way, the data set represents objects of type Y that are related in a specific way to a context object of type X.

Data set parameters are typed with any of the scalar types that Business Intelligence Reporting Tools (BIRT) support. For example you can define a string parameter $name and then write the following row-mapping XPath expression: Class->ownedAttribute[@name=$name].

Object parameters can be represented by a scalar ID that you can use to resolve the object. In EMF and UML models, the unique ID of an object is its URI encoded as a string. Consequently, you select string as the type of URI parameters and bind them to object URI columns at run time.

How to define parameters

For information about defining parameters when you are creating a data set, see the topics "Creating EMF data sets" and "Creating UML data sets."

You can also add parameters to existing data sets. In the data set editor, you start with the Query Parameters page, not the Parameters page, to define parameters for EMF and UML data set queries. You use the two pages as follows:
  • Use the Query Parameters page to add, remove, reorder, and rename parameters. Parameters on this page are identified by the internal name of the parameter. The internal name is the name that you use in XPath expressions, so it must conform to XPath naming conventions for variables; it must start with a letter or underscore (_), and can contain any sequence of letters, digits, or underscore characterss. Changes you make on this page also appear on the Parameters page.
  • Use the Parameters page to complete the definition of the parameter. Specify the display name, which is initially set to the internal name; the type, which is initially set to String; the direction, which is initially set to Input; and the name of the report parameter, if any, to bind to the data set parameter.

After you define a parameter, you can refer to it in both row-mapping and column-mapping queries by using its internal name preceded by a dollar sign ($). When you bind values to a data set parameter on the Data Binding page, you use the parameter display name.

Note: Some information, such as links to Eclipse documentation or to developer guides, is available only from the help topics that are installed with the product.

Feedback