In my previous post I described a feature for conditional pub/sub message delivery using SQL selectors. With that (selector) approach the publisher must attach headers to the message and the subscriber uses an SQL-based condition which references header names and values. In addition to selectors, Backendless supports another type of conditional delivery – subtopics. Consider the following example:
A message with an announcement from Microsoft is published to topic stocks.nasdaq.msft. Another message from IBM is published to stocks.nyse.ibm. Suppose a subscribe wants to receive all messages related to stock announcements. In this case, it subscribes to the stocks.* subtopic. Another subscriber is interested in all Nasdaq announcements. That subscriber subscribers to the stocks.nasdaq.* subtopic. Finally, to receive Microsoft announcements, a subscriber would use the stocks.nasdaq.msft subtopic. As you can see Backendless uses the federated subtopic structure for message filtering/delivery. The sample below shows how to use subtopics in the Backendless messaging API:
Previously I wrote an introduction to Backendless pub/sub messaging which included a sample for broadcasting and receiving messages. Today I am going to show how to use Backendless messaging for conditional message delivery. As you will see in the example, the publisher can attach headers to the published message. The headers is a collection of arbitrary key/value pairs. A subscriber can specify a selector, which is an SQL query defining the condition a message must match in order to be delivered to that subscriber. Each subscriber for the same messaging channel can specify its own selector and Backendless will be handling all of the selectors individually.
In my previous post I introduced the publish/subscribe messaging API. The API can be used to broadcast messages which can be received by multiple client apps.
Note: it is important to distinguish the pub/sub messages from the Push Notification ones. There is a number of technical differences and the purposes where an app should use one mechanism or the other.
When developing and debugging applications which use the Backendless pub/sub API, it may be very handy to publish messages without writing additional code. For this purpose, Backendless console supports the message publishing function. To see it in action, run the subscriber code from the previous post and then:
Publish/subscribe messaging has been around for a long time. The concept is rather simple – a program can publish a message to a queue or a topic, while another program subscribes to the queue or the topic to receive published messages. There are a lot caveats in the model with conditional delivery, message filtering, message transformations, etc. In this post I will demonstrate the most basic form of publish/subscribe messaging. One client will be publishing basic string messages, while any number of other client apps can subscribe to receive published messages. Consider the following example:
Sending an email is a very common operation for many applications. For most of them it is the server-side that is responsible for delivering an email message. Backendless makes it trivially easy to deliver a branded email (meaning it will look like it was sent by your app) in the plain text or HTML formats (or both). Consider the following code which sends an HTML-formatted email message: