Skip to main content

Hello!

 

So my company has traditionally relied on Topics, Subscriptions, and Notifications (which I'll call the 'old way' for short) to send an email when a job fails on the server. It is now wanting to move into Automations, as the perception is that they fully replace the functionality of the old way (and that the old way will be deprecated at some point).

 

I'm looking at the available Trigger protocols and see that, at a glance, the only relevant one appears to be "FME Server Topic Notified". Is this correct?

 

Because if so, it would seem that our perception that Automations fully replace the old functionality isn't accurate, as we'd still have to rely on some of it to trigger the new one in the first place. Can anyone confirm if this indeed the case? Will there be a way to do this through Automations alone eventually?

So say you have a scheduled process, on failure you have it notify a topic and there is a subscriber against that topic to send an email. So when the process fails, you get an email, when it runs successfully, you don't.

 

Now with automatons, you can replicate this in a couple of ways...

 

  1. Trigger your workspace, on the failed port, connect an external action to notify an FME Server Topic. This will be the same topic as used previously
  2. Trigger your workspace, on the failed port, connect an external action to send an email (embed the details)

 

My (personal) preference is option one. The main reason is that by using subscriptions, you can utilise one set of connection details across many automations. If you embed the SMTP details, then if there are changes required to the server, you need to go through each and every process/automation to make changes; verses just making the change in one subscription


Reply