Since its inception, Zato has always offered hot-deployment, which means that it is possible to update code of one's SOA/API services without restarting servers - simply upload a new version of a given Python module and it is automatically distributed to all servers forming a cluster.

The next major version will extend it to user configuration as well - so you will be able to edit any .ini config file on any server and all changes will be propagated to other servers each time that file is saved, just like with services today.

In Zato 2.0 a little piece of code such as the one below can be used to achieve the same effect.

Essentially - after updating a config file, for instance user.conf you need to invoke the 'util.config.reload' service, can be either directly from web-admin, command line or over HTTP, AMQP, ZeroMQ or any other channel.

This will publish an internal message to all servers prompting them to re-read all user-provided configuration files.

In this manner, there is even less need to restart servers - after all, why restart the whole server if only a file or two changed?

# -*- coding: utf-8 -*-

from __future__ import absolute_import, division, print_function, unicode_literals

# Zato
from zato.common.broker_message import SERVICE
from zato.common.util import get_config, new_cid
from zato.server.service import Service

class _Reload(Service):
    name = 'util.config._reload'

    def handle(self):

        server_conf = get_config(self.server.repo_location, 'server.conf')

        self.server.user_config.clear()
        self.server.user_config.update(server_conf.user_config_items)

        self.logger.info('User config reloaded')

class Reload(Service):
    name = 'util.config.reload'

    def handle(self):
        msg = {}
        msg['action'] = SERVICE.PUBLISH.value
        msg['service'] = _Reload.name
        msg['payload'] = ''
        msg['cid'] = new_cid()

        self.broker_client.publish(msg)

While there had been always a plethora of options to install Zato with, under RHEL/CentOS, Ubuntu, Debian or Docker, now a newly added chapter of the documentation explains how to install the Python-based integration platform from source code as well.

This is essentially two commands, one to obtain the code from GitHub and another to run the installer.

$ git clone https://github.com/zatosource/zato && zato/code
$ ./install.sh

Alright, and the third to confirm the installation :-)

$ ./bin/zato --version
Zato 3.0.0pre1.rev-21dbcdfa
$

So here you have it - installing Zato from source - surely will come in handy if you'd like to try out Zato in a system for which there are no pre-built packages or in other situations in which case please drop an email to info@zato.io telling us where elsewhere, in addition to already supported systems, you would like for Zato to run. Thanks!

Overview

A newly released zato-enclog package lets one store Python logs in an encrypted form making it a great fit for environments that cannot keep clear text form of data such as PII (Personally Identifiable Information) in HIPAA-compliant applications.

The package comes with command-line tools to decrypt files, including a command that mimics tail -f functionality to watch decrypted logs as they grow.

Usage examples from Zato ..

from logging import getLogger
from zato.server.service import Service

enclog = getLogger('enclog')

class MyService(Service):
    def handle(self):
        enclog.info('This will be encrypted')

.. and pure Python:

import logging
from zato.enclog import EncryptedLogFormatter, genkey

level = logging.INFO
format = '%(levelname)s - %(message)s'

key = genkey()
formatter = EncryptedLogFormatter(key, format)

handler = logging.StreamHandler()
handler.setFormatter(formatter)

logger = logging.getLogger('')
logger.addHandler(handler)
logger.setLevel(level)

logger.info('This will be encrypted')

CLI screenshots

Key generation:

Screenshot

Demo:

Screenshot

Using tailf -f vs. enclog tailf. The former will show logs in encrypted form whereas the latter will display them decrypted.

Screenshot

Screenshot

Learn more

More information can be found at https://zato.io/docs/progguide/enclog/index.html

Introducing BST

Zato Business State Transitions (BST) is a newly added extension to the core Zato integration platform designed for ESB, SOA, REST, APIs and Cloud Integrations in Python.

Screenshot

BST is a perfect fit for workflow-oriented integrations with multiple applications, Python-based or not, cooperating with a shared definition of a process, such as ones found in Order Management.

Definitions

Definitions of business states and their transitions are written in natural languages, such as English, for instance:

Orders
------

Objects: Order, Priority order
New: Submitted
Submitted: Ready
Ready: Sent
Sent: Confirmed, Rejected
Rejected: Updated
Updated: Ready
Force stop: Canceled, Timed out

Python API

From a Python's programmer perspective, everything boils down to a single with block in a Zato service which:

  • enforces that a given transition is correct for a provided business object
  • executes the block of code
  • on success, transitions the object to a new state
# Zato
from zato.server.service import Service

# zato-labs
from zato_bst import transition_to

class MyService(Service):

  def handle(self):

    with transition_to(self, 'Order', 123, 'ready'):

      # Here goes the actual user code
      pass

REST API

External applications, no matter if in Python, Java, .NET or employing any other technology, can always participate in transitions by using a BST REST API.

Below curl is used to simulate a sample transition for an object of type Customer whose ID is 2 to a state called "Consent given" in a hypothetical process of opening a customer account.

$ cat cust.json
{
 "object_type":"Customer",
 "object_id":"2",
 "state_new":"Consent given"
}
$
$ curl http://localhost:17010/bst/transition -d @cust.json
{"response":
 {
  "can_transition": true,
  "state_old": null,
  "state_new": "Consent given",
  "reason": ""
  }
}

The full API additionally allows to:

  • confirm a transition is valid before executing it
  • perform a mass transition of multiple business objects
  • get history of transitions for a business object
  • return a list of transitions defined in a Zato cluster

Exports and diagramming

A REST API is also available to export existing BST data to either JSON or diagrams, including both definitions and run-time information about the state of a BST instance.

Full control over output is offered, including means to specify custom colors, diagram size or timezones the data should be presented in:

Screenshot

Summary

BST offers new, interesting, means to extend one's SOA or REST environments with a new perspective on how to approach integrations that are primarily oriented towards workflows built on top of individual APIs and endpoints.

Click here to learn more about BST and the the core Zato platform upon which it's based.

Das Akronym ESB und ein damit verwandtes - SOA - kann Verwirrung hervorrufen. ESB steht für "Enterprise Service Bus" - ein Datenbus zur Bereitstellung von Diensten in Unternehmen. SOA steht für "Service Oriented Architecture" - eine dienstorientierte Architektur.

Das macht diese Begriffe noch nicht wirklich verständlich. Daher versuchen wir im Folgenden einige Klartext-Informationen zu dem Thema zu geben, unter Vermeidung allzu vieler Marketing-Phrasen.

Thanks to a great contribution by Chris Zwerschke, the no-nonsense intro to ESB/SOA has just been translated into German.

This is a must read for anyone considering building modern APIs or microservices using contemporary tools and employing current practices.

The document is also available in:

Zato on: