Publishers and subscribers

This page assumes familiarity with publish/subscribe concepts.

Overview

• Publishers are clients that send messages to topics. Any client with appropriate publish permissions can publish messages to topics using the REST API. The publishers can be either REST-based or they can be in Python, which also includes your Zato services in Python.

• Subscribers are clients that receive messages from topics they have subscribed to. Messages are delivered through message queues that are automatically created when a client subscribes to their first topic.

• HTTP Basic Authentication is required for all REST API operations. Each client must provide valid credentials with every request to publish, subscribe, or retrieve messages. You can publish messages either to external REST-based systems or you can publish them to your Zato services.

Permissions

• Pattern-based permissions control which topics a client can publish to or subscribe from. Permissions use wildcard patterns for flexible access control.

• Single wildcard * in permission patterns matches one topic segment. For example, pub=orders.* allows publishing to orders.processed and orders.cancelled.

• Multi-level wildcard ** in permission patterns matches multiple topic segments. For example, sub=alerts.** allows subscribing to alerts.critical, alerts.critical.system, and any deeper nested alert topics.

• Permissions are skipped for services which means that your Zato services can always publish messages to any topic, and they don't use any patterns at all, you can publish to any topic from any service.

Message Delivery

• Pull-based delivery is used for REST API subscriptions where clients call the /messages/get endpoint to retrieve messages on demand with configurable limits on message count and total data size.

• Push-based delivery can be configured for subscribers to have messages automatically delivered to their REST endpoints as soon as they arrive, without requiring polling. When you publish messages to services, Zato will always push messages to them, that is, your services don't ever pull messages from queues.

• Automatic acknowledgment happens when messages are retrieved. Once pulled from the queue, messages are immediately removed and cannot be retrieved again.

How to create topics, subscriptions and permissions?

Use test config for experimentation

• Remember that you can start off by importing the test configuration - it's a set of demo credentials and topics, all configured to work together
• The username/password will be user.1/password.1
• You can import the test config multiple times - don't worry that you'll break anything, it's there specifically to let you play around and learn things in practice. You can delete or modify it at will and if you'd like to start over, simply click import again

Adding credentials and configuring permissions

• Start by going to Security → HTTP Basic Auth and adding new credentials, let's say it will be user.2/password.2 (don't forget to click Change password too).

• Now go to EDA → Topics and create a new topic, e.g. my.topic.1

• Now go to EDA → Permissions and assign permissions as in the example below.

• Each security definition can be a publisher, subscriber, or it can be both, and you can assign permissions to each role independently.

• At this point, you'll have the configuration sufficient to publish messages to topics, but you won't be able to receive them yet. This is because merely adding permissions for subscriptions doesn't create the actual subscriptions, so let's do that now.

Creating subscriptions

• Go to EDA → subscriptions, select one of the security definitions and then select one of the topics you'd like for the security definition to subscribe to. Note that only the topics that this security definition has permissions for will display in the form.

Next, select how messages will be delivered for that subscription.

• If you choose Pull for the delivery type - your subscribers will be able to use the REST API to access their messages

• If you choose Push, this will tell Zato to deliver messages to either one of your services or to one of the REST outgoing endpoints (configured via Connections → Outgoing → REST). In either case, the security definition that this subscription is for will still always be able to pull the messages on its own.

Getting started with EDA

Using EDA