Workspaces as a Subscription AND a Publication
We've looked at how to set up a workspace to subscribe to notifications, and how to set up a workspace to publish notifications. A workspace can do each task individually, but when it is set up to both subscribe to and publish notifications, the overall setup looks like this:
In this scenario the same workspace receives an incoming notification sends an outgoing notification. It is set up as a workspace subscription (in order to receive incoming notifications) and registered with the notification parameters set on a different service (in order to send outgoing notifications).
For example, details of a lightning strike are received via a LightningStrike topic. The workspace then processes the information – for example it determines which state/province/county the strike occurred in – creates a new message and dispatches it to subscribers via a WeatherAlert topic.
The important thing to notice is that the scenario involves two different topics, here Topic I and Topic II.
A major problem occurs if you set up such a scenario but only use one topic. That’s because for every notification the workspace receives it will publish back to the same topic, triggering itself again and causing an infinite loop of messages.
| Daily Interop Reporter, Chad Pugh-Litzer says … |
|
Using the same topic for incoming and outgoing notifications is like setting up your email to forward all incoming messages to yourself; or like automatically retweeting your own tweets. You’ll end up with a loop that continues until you crash the system!
To avoid confusion it’s a good idea to clarify which topics are for in and out communication through their names. For example, use LighningStrike_In and LightningStrike_Out to differentiate topics that are triggered by incoming alerts and those triggered by outgoing alerts. |