Next in the row of my BAM series will be the BAM Parameters.
First some theory from the oracle documentation
A parameter is a variable representing the value of a data field. A filter is a condition applied to data retrieved by a query or view, which can reference one or more parameters. A prompt is a request for the user to specify the value of a parameter. For example, you can filter an asylum cases query by judicial authority, create a parameter for the judicial authority, and prompt the user to choose the judicial authority when the query is referenced by a view in a dashboard.
A parameter can have a default, which can be a specific value or a special value such as ALL or NULL. For example, a judicial authority view could show cases for all judicial authorities by default.
There are two types of parameters: value parameters and list parameters. A value parameter can accept only one value and does not explicitly reference a specific data field. A list parameter can present and in some cases accept multiple values and references a specific data field.
Users can use datetime parameters, including the system datetime, to limit data based on a time span. Other datetime values are based on the time zone selected in user preferences.
I started with the creation of a parameter.
After creating parameters, you can use them in the following ways:
In a query
A query can reference parameters in filters. I have done this in the Logo’s, Opened and Closed Tasks, Opened and Closed Tasks Without Timing, Organizational Parts.
In a view
A view can reference a query that references parameters. However, you cannot do anything with a parameter in an individual view.
In a dashboard
A dashboard can contain a view that references a query with parameters. The dashboard can prompt the user for the parameter values.
Several of the views on this dashboard make use of the parameter. Data displayed is depending on this filter. By default (even while they are not checked) all data is show.
More about this in the Dashboards post (BAM Dashboards).
In a parameterized message alert action
I have not used this in my Dashboard. For queries or views that contain filters with parameters, only one alert action option is available. See also the BAM Alerts post.
Next I will shortly mention some special situations.
- On a DataObject level it’s also possible to use parameters. These can then be used in Calculated Fields. An example of this I already mentioned in the BAM Data Objecten post.
- You can specify parameter values in the dashboard URL. You can use this URL in a Web page in a portal site or as a link in an e-mail. E.g.
This URL contains multiple parameters. One of them is the ‘JudicialSystem’ with the value ‘AR0044’. Although this filter is applied correctly to the data, this is not visible in the parameter.
- Driving Parameters from Other Views
Changing a view by making a selection in another view is called driving. Driving enables you to use a selection in one view to drive a parameter in another view. For example, you can use a column in a List view to drive a Bar chart view that shows a subset of the data in the list.
To be driven, a view must reference a query with a parameter used in a filter. Also, if drilling is enabled, driving will not work. Drilling overrides driving.
The view that drives the other views, the driver, need not reference a query with a parameter.
This image is only as an example. In my dashboard driving will not work, because the Organizational Parts view has drilling enabled.
This brings me to the end. You can download the Parameters and the other related objects here.
In the next post I will do the Alerts.