While JSON or SOAP-wrapped messages are ubiquitous in HTTP-based APIs, there are times when unformatted messages are of advantage.

This article will explain how to create Zato endpoints accessing such data and to top it off, will also introduce the concept of outgoing FTP connections through which requests can be stored at remote FTP resources.


Hot-deploy the following service onto a Zato cluster.

The key point is self.request.raw_request - this is how a programmer can access input data as it was received by Zato prior to its de-serialization from JSON or XML.

Note that this attribute will be available even if parsing took place, that is, one can always access raw request no matter what data format was used on input.

# Zato
from zato.common.util import fs_safe_now
from zato.server.service import Service

class FTPHandler(Service):
    """ Stores anything that is given on input at a remote FTP server
    pointed to by an outgoing connection called 'my.ftp'.
    def handle(self):

        # Obtain handle to an FTP connection by its name
        conn = self.outgoing.ftp.get('my.ftp')

        # Create file name in a format that is safe for file-systems,
        # i.e. no colons or whitespace.
        file_name = '/home/api/request.{}'.format(fs_safe_now())

        # Store file on FTP
        conn.setcontents(file_name, self.request.raw_request)


Now that the code is deployed, we need configuration to plug it into the whole framework. Use web-admin to create two objects per screenshots below.

One is an HTTP channel that exposes the deployed service through an HTTP channel - note that 'Data format' was left blank so as not to require JSON or XML on input.


The other is a definition of the FTP server that the service will store files in.


Don't forget to set password for the newly configured FTP connection to log in with in run-time.


As always with Zato, one's code never accesses any resources directly, everything is routed through named objects such as self.outgoing.ftp['my.ftp'] that actually point to a required resource. In this manner, if anything needs to be reconfigured, it can be done on fly, without changes to code and without server restarts.


With code deployed and configuration created, we can now upload sample data from command line and confirm it's made its way to an FTP server.


And sure enough - the file is there!




Accessing raw requests in Zato services is trivially easy. Likewise, making use of FTP connections is a matter of a single line of code, while hot-deployment and configuration mean that changes introduced in web-admin are immediately reflected all throughout a Zato cluster.

Want more?