Pub/sub subscribers

• Subscribers are pub/sub endpoints that receive messages that were previously sent (published) by publishers.
• To receive messages, subscribers first create a subscription. Each subscription has a unique subscription key which serves as its identifier.
• Subscribers can be of several types: Python, REST or WebSockets. WebSockets always subscribe to topics through API calls - their subscriptions cannot be created in advance in Dashboard.
• REST and WebSockets use Basic Auth to identify themselves with the message broker.
• Pattern-based permissions are assigned to each subscriber. If, during the publication of a message, a particular subscriber does not have permissions to receive messages from the topic the message is sent to, that subscriber will not receive the message. Python subscribers (Zato services) are always allowed to receive their own messages, i.e. each service can always receive messages from a topic that points to this service.
• It is possible to create more than one subscriber for a given application, e.g. to represent different permissions assigned to different parts of the same application. Each subscriber will use a different subscription key.
• Messages being delivered to subscribers can be processed - e.g. transformed or enriched. For instance, each message can be converted from one format to another, or parts of a message can be replaced with the results of an API invocation. The process is transparent to the subscribers that do not need to be aware of it.

Subscriptions

Provided that there are correct permission patterns and that relevant topics already exist, each REST or Python (service) endpoint may subscribe to one or more topics.

Note that services can subscribe to two kinds of topics:

• Explicitly created ones, such as /customer/new in the screenshot above
• Topics created for each service implicitly on demand - whenever a message is published to a service by its name, a topic for that service will be created and the service will subscribe to it automatically, unless such a topic already exists. All such topics have a prefix of "/zato/s/to/" followed by a name pointing to the service's name. For instance, if your service is called my.api.customer.new, its implicit topic's name will be /zato/s/to/my_api_customer_new.

Delivery of messages for each subscription is always carried out by a single server, called a delivery server for that subscription. This ensures correct message ordering - if there are multiple servers in a Zato cluster each receiving messages ultimately destined for the subscription, they will be forwarded to that subscription's delivery server first. For in-RAM messages, they are kept in the delivery server's RAM.

Messages can be sent on a notify or pull basis. The former means that Zato itself will be invoking the endpoint with new messages whereas pull means that Zato will queue messages up and the recipient itself will periodically read the contents of its queue. Regardless of the delivery type, messages can be sent one-by-one or in batches of a pre-configured size.

Delivery of a message can be repeated up to a configured number of times, with a sleep time in between them, configurable depending on what kind of error was encountered - a TCP socket-level one or a different one.

For each type of an endpoint, this endpoint type's specific options can be provided - for instance, the endpoint in the screenshot above is a REST one so an HTTP method can be specified that should be used to deliver messages with.

Each endpoint may subscribe to topics multiple types and each time it is given a new subscription key - this is a secret that must be known only to the participant to whom it was issued.

Quick links