# PubSub by Workato

The PubSub connector enables you to implement integration solutions that require an event-driven, message-oriented architecture that decouples publishers and consumers. The connector implements a messaging system with support for guaranteed and persistent delivery. This allows us to chain recipes sequentially, as a recipe can publish a message that multiple other recipes consume as a trigger to kickstart their workflow.

This connector allows us to add or modify recipes which are consumers without affecting recipes which are publishers. This enables zero downtime for the publisher recipe as we can add new consumers without impacting or requiring changes in the publisher recipe. This decoupling results in simpler recipes and reduces the time required to create, test, and maintain recipes.

# How to connect to the PubSub connector on Workato

There is no connection required to use the PubSub connector, as schemas are stored in the Workato account for recipes to interact with.

In order to work with the PubSub connector, users require access to the PubSub topics feature. Reach out to your Customer Success Manager to learn more.

# How to use PubSub topics

You can go to the PubSub main page by clicking Tools > Pub/Sub Topics. Here, you can view all the topics that are active on your Workato account.

Manage topics in PubSub Manage topics in PubSub

You can use the search topics function to quickly locate topics by keyword.

# Creating and managing topics

In order to work with PubSub messages, you have to first create and define a topic. So publishers and consumers alike know what to expect when sending or receiving messages.

Select New topic to get started.

New topic New topic

When creating topics, you will need to define what the messages will look like.

Field Description
Name The name of your new topic.
Schema The message fields for this topic. See more here.

# Topic schema configuration

When creating topics, you will need to define what the message will look like. This structure can be subsequently edited.

Defining topic schema Defining topic schema

Field Description
Name The name of a new message field.
Data type Select the data type from a dropdown.
Optional Choose if this message field is optional. Default is No.
Hint Provide a hint for this message field.

Besides entering each field manually, you can define the topic schema with a sample json.

# Working with the PubSub connector

After configuring your topics schema, you can now subscribe to messages using the New message trigger or publish messages using the Publish message action

# Using the new message trigger

The new message trigger allows us to subscribe to a specific topic in Workato. Any messages published to that topic will be picked up by the trigger as a single trigger event.

New message trigger configuration Select the topic to configure the new message trigger

# Using the publish message action

The publish action allows us to publish messages to a specific topic in Workato. Any messages published to that topic will be picked up by the new message trigger as a single trigger event.

Publish message action configuration Select the topic and fill in the input fields to configure the publish message action

# Example scenario using the PubSub connector

For example, we have a recipe that creates leads in Salesforce upon receiving a WebToLead HTTP request, built to retrieve contact data from leads who filled in a form online. After creating the lead, the recipe updates an analytics database in Postgres.

Original recipe Recipe moving leads from an online form to Salesforce and PostgreSQL

If our organization was to change databases from PostgreSQL to RedShift, and start using MailChimp as a mailing list application, we have 2 approaches we can take.

  1. Modify the original recipe without using the PubSub connector

We would need to update our recipe as follows.

Modified recipe Modified recipe to add rows to Redshift instead of PostgreSQL and add subscribers to MailChimp

The change to the original recipe would require additional iterations of the recipe development lifecycle, as the recipe would need to be modified, tested for backward compatibility, and pushed to production. Any bugs slipping through QA would result in downtime for the production recipe.

  1. Use the PubSub connector

If we were utilizing the PubSub connector and queues, we could have built the original recipe in this way, to create a Salesforce lead before publishing the lead data to a topic. This recipe will not need to care about its consumers, and therefore it does not need to know that downstream recipes are changing from PostgreSQL to Redshift, or that there is an additional consumer writing to MailChimp.

Publisher recipe Publisher recipe that creates a lead in Salesforce and publishes lead data to a topic

The corresponding consumer recipe that creates a Redshift row with the lead data will look as follows.

Consumer recipe creating Redshift row Consumer recipe that consumes the lead data from the topic and creates a Redshift row with the lead data

The corresponding consumer recipe that creates a MailChimp lead with the lead data will look as follows.

Consumer recipe creating MailChimp lead Consumer recipe that consumes the lead data from the topic and creates a MailChimp lead with the lead data