Messaging (8 posts)

In this article, we’ll talk about Backendless publish-subscribe messaging. One of the frequent questions we receive is: ‘How to get messages long after they are published.’ The default mechanism in Backendless keeps messages in the published channel for a short period of time only (around a minute). This becomes a problem if subscriber needs to have access to the messages after that time period has passed. This article describes an approach for storing published messages in Backendless database in order to keep published messages accessible even when they are no longer present in a messaging channel.

Publish-subscribe is a Backendless messaging pattern. The main idea here is to exchange data between a publisher* and subscriber** within a messaging channel***.

publisher – a program using the Publishing API to send messages to a channel.
** subscriber – a program using the Subscription API to receive messages from a channel.
*** channel – a logical intermediary “transporting” the messages.

In order to keep messages accessible for an infinite period of time – you can save messages into the Backendless database right after they were published. To accomplish this, we’ll need to combine Data service API and the afterPublish event handler which can be added to the Business Logic tab of your Backendless application.

handlerConfig 1024x565 - How to save published messages in the database

Once it’s added, just download the afterPublish handler code from ‘Download’ menu (you can select JavaScript or Java). Then open the generated project in any IDE and add the code to store published messages in a Backendless data table.

Alternatively, the afterPublish event handler can be added and deployed to cloud without any coding at all using Codeless business logic. Here are the steps of how it can be done:
1. Add new Codeless event handler Selection 143 1024x519 - How to save published messages in the database2. When the handler is saved, Codeless designer will be opened. Add the following blocks to your Codeless logic. When done – click the ‘DEPLOY MODEL’ button.
Selection 144 1024x535 - How to save published messages in the database

To avoid nulls, every message should be published with a not null value for publisherId :

For this scenario we’ll need to create a data table (Data > APP TABLES in your Backendless application) called ‘ChatHistory’ and define the following schema in it:

  • Column publisher of type String 
  • Column messageData of type String 

dataTable 1024x557 - How to save published messages in the database

Once code for the handler is added, deploy the handler code to cloud using the following command in your IDE terminal:
Since the handler is deployed, every new message published to chatRoom channel will be stored in a dedicated data table and will be accessible at any required moment by calling an API to retrieve data from a table:

You will receive the following output:

Backendless Push Notifications are getting a much-needed facelift. Today, with the release of version 4.3.0 you will start noticing some improvements. Specifically, you will see the  DeviceRegistration data table:

devicereg table - Rethinking Device Registrations for Push Notifications

Continue reading

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 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:

Continue reading

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.

Continue reading

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:

  1. Login to Backendless console, select your app (must be the same app which the subscriber app uses) and then click the Messaging icon.
  2. Make sure the default messaging channel is selected. Enter the text of the message into the Message text area and click the Publish button.
  3. The message will be displayed in the table of messages in the Messaging screen as shown in the image below. Additionally all the subscriber apps receive the message.

published message - Feature 66: Send pub/sub messages from Backendless console


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:

Continue reading

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:

Continue reading
Find us in facebook