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.
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
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.
For information about defining parameters when you are creating a data set, see the topics "Creating EMF data sets" and "Creating UML data sets."
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.