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 eitherDEPLOY
orUNDEPLOY
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 toDEPLOY
, 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 toUNDEPLOY
, 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.