Publishers and subscribers

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.

• Message ordering follows priority-based delivery where higher priority messages (0-9, with 9 being highest) are delivered first, then by publication time within the same priority level.

• 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.

Managing subscriptions

• You can configure whether an existing subscription is enabled or not - separately for delivery and message publications. You can also configure whether the delivery for a subscription is active, temporarily disabled or off.

• This is useful, for instance, during updates to the external systems that use your message broker. As an example, let's say you integrate with a system that is being updated to a new version so it will be temporarily offline.

  You can mark such a subscription as temporarily disabled so Zato won't be making any attempts to deliver messages to this system, while all publishing systems won't have to be aware of that. From their perspective, they'll continue their publications as usual.

• When using the "Enabled for" flags, you're doing it for all the topics within a subscription, e.g. turning off the "Enabled for delivery" flag will prevent any deliveries for that subscription.

  On the other hand, when you temporarily disable delivery, it's always on a topic-by-topic basis, by clicking a checkbox next to each such topic. It's a 3-state checkbox and clicking it will cycle through the states: active, disabled and off.

In the example above:

• my.topic.1 has an active subscription and its delivery is active, so the subscriber will receive its messages
• my.topic.2 has an active subscription but its delivery is disabled, so the subscriber won't receive its messages
• my.topic.3 doesn't have any subscription for that topic, so it won't receive its messages

Getting started with EDA

Using EDA