Apama 10.15.2 | Developing Apama Applications | Developing Apama Applications in EPL | Defining Queries | Implementing parameterized queries
 
Implementing parameterized queries
 
Parameterized queries as templates
Using the Scenario Service to manage parameterized queries
Referring to parameters in queries
Scaling and performance of parameterized queries
An Apama query can define parameters and then refer to those parameters throughout the query definition. This enables a query definition to function as a template for multiple query instances.
A query that defines parameters is referred to as a parameterized query. An instance of a parameterized query is referred to as a parameterization.
A parameterized query offers the following benefits:
*Patterns of interest (find patterns) may be customized from a single generic query. This can significantly reduce the amount of code that needs to be written and maintained.
*Parameterizations exist only at runtime. There is no need to maintain a file for each instance.
*Parameters can be used throughout the query in which they are defined. For example, you can use them in the definition of inputs, in find actions, and in user-defined actions. Values do not need to be hardcoded.
You define query parameters in the parameters section of a query definition. See also Format of query definitions. The format for specifying the parameters section is as follows:
parameters {
data_type parameter_name;
[ data_type parameter_name; ]...
}
In the following example, the parameters section is in bold as are the references to the parameters.
query FaultyProduct {
  parameters {
       string product;
       float thresholdCost;
       float warrantyPeriod;
}

inputs {
Sale() key customerId within warrantyPeriod;
Repair() key customerId retain 1;
}
find Sale() as s1 -> Repair() as r1
where s1.product = product
and r1.product = product
and r1.cost >= thresholdCost
{
log "Cost of warranty covered repair for product \"" + product +
"! above threshold $" + thresholdCost.toString() + " by $
" + (r1.cost - thresholdCost).toString() at INFO;
}
}
See also: Query lifetime.