Deployment Receivers

A Deployment Receiver acts as an endpoint for local and remote Deployment Handlers that seek to ship their Deployment Packages to a destination. These are frequently used to move content between data centers or across different parts of the world to solve for latency issues (or to simply move content to the correct side of a DMZ for security reasons or runtime-performance reasons).

Cloud CMS lets you create Deployment Receivers from within its user interface. You can create as many Deployment Receivers as you would like. Each Deployment Receiver is local by default which means that only Deployment Handlers on the same Cloud CMS platform may connect to it. However, you may designate a Deployment Receiver to be remote by simply clicking on the checkbox within the user interface to indicate so.

Remote Access

Deployment Receivers that are marked for remote access will be available within the API at the following HTTP address relative to the server root:

/deployment/receivers/{deploymentReceiverId}/push

To connect to a Remote Deployment Receiver, you should configure a Remote Deployment Handler. The Remote Deployment Handler automatically takes care of all of the packaging, connectivity and handshaking between a Cloud CMS platform and the Remote Deployment Receiver endpoint.

Building your own Deployment Receivers

To build your own Deployment Receiver, you will need to implement the following API method:

POST /deployment/receivers/{deploymentReceiverId}/push?operation={operation}

Where:

  • deploymentReceiverId is the ID of the receiver being invoked. For custom deployment receivers, this can be any identifying value.
  • operation is either DEPLOY or UNDEPLOY

The payload will consist of a Deployment Package JSON and an Archive (binary ZIP). The API method must handle multipart POST and should check for two important parts:

  • one part which is application/json and contains the Deployment Package JSON
  • one part which is application/zip and contains the Archive (binary ZIP)

The custom HTTP Deployment Receiver will need to unpack the ZIP and traverse the ZIP structure to make sense of what was sent to it.

There are two operations;

  • if operation is set to DEPLOY, the records contained within the Deployment Package should be written to the target. If there are collisions, the new content should overwrite the old.
  • if operation is set to UNDEPLOY, the records contained within the Deployment Package should be deleted from the target.

Cloud CMS Deployment Receivers allow you to configure downstream Deployment Targets which will receive the Deployment Packages for processing. Custom Deployment Receivers are under no requirement to provide such functionality. A Custom Deployment Receiver may instead elect to just do its processing straight away.

The transactionality of the Deployment Receiver is implementation-specific. Most Deployment Receivers will opt to continue deploying or undeploying even if a single record within the Deployment Package fails. However, depending on your requirements, you may wish to have the contents of the Deployment Package commit differently (or atomically). It is entirely up to you.