Hi David.
For the second data action, to query multiple queues, you'd need to convert the array of queue IDs into an array of predicates that could be included in the request body. Unfortunately I don't know of a way to do that in the data action itself, so your best option is probably to build up the predicate expression in architect before you call the second data action.
E.g. Your architect flow would take the IDs returned from the first data action, then loop through them and convert them into one of the following: ideally (a) an array of predicates; or if you can't get that to work, (b) a single string containing the predicate expression which you can embed into the request body; or worst case, (c) a single string containing the entire request body [to use in the second data action]. (Sorry I'd like to tell you which option would work best but without actually creating all this stuff myself I don't know the answer.)
Taking the optimistic approach and going with option (a), then the architect flow would create an array of predicate objects that would look something like this:
[
{
"type": "dimension",
"dimension": "queueId",
"operator": "matches",
"value": "<queue-id-1>"
},
{
"type": "dimension",
"dimension": "queueId",
"operator": "matches",
"value": "<queue-id-2>"
}
]
The above array would be passed into the second data action, and you'd embed it in the response body using something like this:
{
"filter": {
"type": "and",
"predicates": [
{
"type": "dimension",
"dimension": "mediaType",
"operator": "matches",
"value": "voice"
}
],
"clauses": [
{
"type": "or",
"predicates": ${input.predicateArray}
}
]
},
"metrics": [
"oWaiting",
"oAlerting",
"oInteracting"
]
}
Also since the data action response will contain multiple queue statistics, you'll want to get rid of $successTemplateUtils.firstFromArray() from your successTemplate, and aggregate them in the translationMap using the sum function. So your response definition might look something like this:
{
"translationMap": {
"waiting": "$.sum($.results[*].data[?(@.metric=='oWaiting')].stats.count)",
"interacting": "$.sum($.results[*].data[?(@.metric=='oInteracting')].stats.count)",
"alerting": "$.sum($.results[*].data[?(@.metric=='oAlerting')].stats.count)"
},
"translationMapDefaults": {
"waiting": "0",
"interacting": "0",
"alerting": "0"
},
"successTemplate": "{ \"WaitingCount\": ${waiting}, \"AlertingCount\": ${alerting}, \"InteractingCount\": ${interacting} }"
}
NB: I've used $.sum(...) rather than tacking .sum() on at the end of each line because it better handles the case where the stat isn't present. Having said that though, the translationMapDefaults above also deal with this situation, so it is really just a matter of taste.
Hopefully this all makes some sense? I'd suggest you implement these recommendations incrementally to make it easier to detect syntactical errors that I might have made above?
Nick.
------------------------------
Nick Tait
Genesys Consultant
------------------------------