Apama Documentation : Developing Apama Applications : Developing Apama Applications in EPL : Defining Queries : Defining query input : Using the output of another query as query input
Using the output of another query as query input
While it is possible to have a query send an event explicitly containing all of the coassignments in the pattern or aggregates using the %send construct, this requires setting each field and defining an event type, which currently can only be defined in EPL. In this case, however, this event definition needs to be kept in sync with the query. If the query pattern is modified, then the query's %send construct and the event definition may both need to be updated. It is therefore recommended that you use the query output event to chain queries together.
Every query will automatically generate a query output event, which can be used as an input to other queries. This makes it easy to connect multiple queries together. One query may compute an aggregate such as an average over a sensor reading, while another query checks if a number of averaged readings match some condition.
The query output event
With each query definition, a query output event definition is automatically defined which is named after the query (see below) and has all of the values available to actions defined as fields.
The query output event definition comprises:
*All parameters.
*All keys (using the alias name).
*For find patterns:
*All "positive" event coassignments (that is, excluding without events and wait nodes).
*For find every patterns (that is, a query which contains aggregates):
*All aggregate select values.
Consider the two examples below, where we assume that the Measure event is defined as follows:
event Measure {
string deviceId;
integer userId;
float value;
}
Example 1
query Q1 {
parameters {
float threshold;
}

inputs {
Measure() key deviceId within 5 minutes;
Error() key deviceId within 5 minutes;
}
find Measure:m1 -> (Measure:m2 or Error:e1)
without Error:err {
}
}
Query output event definition for Q1:
event Q1 {
float threshold;
string deviceId;
Measure m1;
optional<Measure> m2;
optional<Error> e1;
}
In query Q1, the parameter threshold of type float, the solitary input key deviceId of type string, and the positive coassignments m1, m2 and e1 are mapped in the query output event Q1. m2 and e1 are wrapped in optional since they might or might not contain any value (just m2 or e1 is enough to trigger the find pattern).
Example 2
package com.apamax.mypkg;
query Q2 {
inputs {
Measure() key deviceId, userId as id within 5 minutes;
}
find every Measure:m1
select mean(m1.value):avg_value
select last(m1.userId):last_value{
}
}
Query output event definition for Q2:
package com.apamax.mypkg;
event Q2 {
string deviceId;
integer id;
float avg_value;
integer last_value;
}
In query Q2, which uses aggregates, both the keys deviceId of type string and userId (aliased as id) of type integer are mapped in the query output event Q2. The query contains two select statements both of whose values are also mapped in the query output event.
Note that the query output event definition resides in the same package as the query, and that it can be used in any EPL application in the usual way you use any external event definition.
Note:  
Only the first 32 fields of indexable event types can be used in listeners. Beyond this, fields will be marked as wildcard fields. See Improving performance by ignoring some fields in matching events for more information on wildcards.
When is the query output event generated?
Whenever a query's find statement triggers, the query output event is routed, no matter whether it was triggered by an event or a timer firing. Another query can use this query output event as an input, thus allowing the "chaining" of one query to another.
For example, query Q3 below uses both Q1 and Q2 as input:
using com.apamax.mypkg.Q2;
query Q3 {

inputs {
Q1() key deviceId within 5 minutes;
Q2() key deviceId within 5 minutes;
}
find Q1: q1 and Q2 : q2 {
print "Query Q3 is triggered";
}
}
Q3 will trigger on receiving the inputs of type Q1 and Q2. Hence, Q3 will trigger when both queries Q1 and Q2 trigger.
Note:  
It is recommended to use separate packages for queries (and hence the query output event) and any external event definitions defined in EPL. This makes it clear where the event definitions are and avoids name clashes.
Cycles are illegal. For example, if a query Q2 uses Q1 as input and if Q1 in turn also uses Q2 as input, any such cyclic dependency is illegal to use.
Copyright © 2013-2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback