Skip to main content

Scenario: Queue Processor

Complete Scenario​



Our scenario is built of 4 distinct stages, as defined in the Solution Workflow:

  • Stage 1: Query the campaigns table and get an array of campaigns to be examined.
  • Stage 2: Query the voice applications tables and get an array of voice application CXML documents or a remote URL.
  • Stage 3: Iterate through the campaigns:
    • If the campaign is valid for execution (date, time of day, status), get 10 records from the queue from this campaign.
    • Iterate the queue records and based upon the voice application issue out the relevant Cloudonix module.
  • Stage 4: Once a call is running, its updates will be recorded by the Status Watcher. The Status Watcher is used to record specific events, related to the operations of each outbound call.

Stage 1: Query Campaigns​



Our goal is to retrieve an array of campaigns to be examined. This is done by querying the campaigns table in the AirTable Data Store. Once we have the campaigns, we can proceed to the next stage.



Stage 2: Query Voice Applications​



Our goal is to retrieve an array of voice applications to be used in the campaign. This is done by querying the
voice applications table in the



Stage 3: Process Queue​



At this point, our queue processor will iterate through the campaigns, and for a campaign it will iterate through the available valid entries in the queue for processing.



If the entry in the queue is valid, the queue processor will invoke the Make call and do something smart module.

Stage 4: Initiate the outbound call​



Based on the value of the voice application field in the queue entry, the queue processor will invoke the relevant branch - either a url based voice application or a cxml based voice application. The call will be initiated and the Status Watcher will be invoked accordingly.