Container Application

For the impatient

You may explore this data model via the API Playground, by clicking here

Endpoints

/applications[/{application-name}] (alias to /customers/self/applications[/{application-name}])
/customers/{customer}/applications[/{application-name}]

The Container Application model stores an installation of a voice application that is hosted and served directly from Cloudonix servers. The software source code that executes the Cloudonix voice application is stored in Cloudonix servers and is executed on-demand by the Cloudonix APP.core voice application runtime - in a similar way to how "severless applications" are hosted in Amazon Web Services Lambda or Azure Functions.

Container Applications are stored for a customer (not a domain) so the same voice application can be deployed to multiple domains without requiring a duplicate installation. Each Container Application is identified by a unique name (unique for the tenant - different tenant accounts might have different voice applications with the same name) and are made up of one or more named "blocks" - which represent the different steps in the application control flow. Every application must have a block named "main" which is the first block that will be executed with the application is being run. The main block can then perform operations that will call other blocks.

A block result must be a CXML document that lists some CXML operations that the Cloudonix APP.Core voice application runtime engine performs sequentially until a callback is sent to another (or the same) block, or the call disconnects - this is the same as what would be a single "page" or a "web service API call" in a customer hosted voice application: each block starts with a CXML request and generates a CXML response document. When the Cloudonix APP.Core voice application runtime engine executes the block CXML response, it may generate a callback event that will trigger the Container Application block again (or it can also trigger a CXML request to a customer hosted voice application - its all up to the application developer).

A Container Application is addressed using a URL with the "cx:" schema, with a URL authority ("host name") hardcoded as "hosted-app", with the path part of the URL denoting the application name and the block name. For example, to deploy an domain voice application configuration that invokes the customer hosted voice application installation named "my-app", set the voice application URL to cx://hosted/my-app/main. Application blocks can setup event callbacks to trigger another named stage by just specifying the name of the block in the callback URL. For example to send the result of a Dial TwiML operation to the block named "dial-result", use {Dial action="dial-result"} - Cloudonix APP.Core will correctly parse this relative URL to execute the next block in the same application.

Container Applications blocks can be implemented using any of the runtimes supported by the Cloudonix API.Core Container Applications environment, which currently include the following:

javascript : ECMAScript 2018 compatible
ruby : Ruby 2.5 compatible
static : Static CXML documents
forward : Forward the request to an external HTTP/HTTPS resource to provide the block response
select : A static document that maps caller's input to other blocks - useful for quickly implementing IVR routing trees

The Container Application model represents a complete hosted voice application, though operations on the model are always done on a block by block basis.

Properties

Property	Type	Editable	Description
`name`	`String`	Create	The name of the Container Application
`url`	`String`	No	The URL that can be used to set up the application for a domain
`blocks`	`Array`(`Block`)	No	A list of the blocks in the application (see below)

To create an application, POST the main block to the Container Applications API endpoint.