Question

FME Server 2019 automations

  • 27 February 2019
  • 7 replies
  • 1 view
todd_davis
Rank
Userlevel 1
Badge +12

Hi,

Currently looking at the FME Server 2019 beta (build 19213) automations, which so much easier to understand from a publisher aspect, compared to "Notifications". However, I noticed that when you choose "triggers" or "external actions" such as sending an email, you need to fill out all the configuration details each time? There is a copy-paste option in a single automation, but that doesn't seem to work between automations.

Maybe that could also look differently, allowing users to have private/public actions and triggers (e.g. like connections in FME Desktop)

Also, if a one configuration is used multiple times (and all these get different id in the current setup based on the json responses I am seeing), how do you update a single email (or any other trigger or action) configuration in the UI. Yes, you can do via rest api (although it isn't currently documented) but if you don't, someone would have to go through all the automations looking for the thing that they may need to change.

From an FME Server audit aspect, I am going to end up with hundreds of of the same "actions" and "triggers", which is going to make it a bit more difficult than it use to be, so looking at the ways I can get a win in that space.

Interested in thoughts, and will post a few ideas.

Cheers,

Todd

https://knowledge.safe.com/idea/87716/fme-server-automations-update.html

https://knowledge.safe.com/idea/87710/fme-server-automation-templates.html

 

7 replies

J
Badge +2

Hi @todd_davis

 

 

Thanks so much for taking the time to play with automations and give your feedback!

 

 

The repeat configuration steps, especially for email, has been brought up already internally. I believe it would be significant development effort to allow that to happen. I'm imaging that it would be like an expansion of the current web/database connections functionality that we have in desktop. Even being able to save defaults as you can with transformers would be useful.

One option you could do for the multiple configurations issue would be to create a automations/notifications hybrid. So if you want to use the same email publication/action several times or need to update it, you could create the rest of the automation and then create an email publication and use the automation to trigger that publication. Whilst not the tidiest approach, whilst we're at the early stages and first release of automations I think this would give you what you're after. You'd also then only need to update it in one place, if something like the password or template needed to change. And as the notification service isn't going away, for experienced users in some cases that may be the best solution. I think the hope here is automations will enable more one-off workflows to be created and help new users leverage this capability.

If you do post all of these ideas, it might be nice to also link them here so anyone who comes across this post can contribute in a specific location to that idea.

 

 

I'll definitely pass this post on to our Server Development team, and if anything else comes out that will help with this I'll let you know.

 

And definitely keep playing with automations and let us know what you think!
todd_davis
Rank
Userlevel 1
Badge +12

Thanks @jlutherthomas

Like you mention, I will probably rely on the topic notification via the automations in the meantime for us (not sure I can force that on clients though). I am going to see how I can report on the automations in an understandable format, so might have some comments, once I have really had a play with the api side.

 

 

 

todd_davis
Rank
Userlevel 1
Badge +12

Also, if you don't fill out details within the automation, there is no warning that you have left things empty.

Another idea lodged:

https://knowledge.safe.com/idea/87723/fme-server-automations-warn-when-processes-incompl.html

david_r
Rank
Userlevel 4

I totally agree.

My take after having played around just a little bit: it would be really useful if there was some global key/value storage for the automations, which you could reference wherever in the configuration. Something just like workspace published parameters, in fact.

That would allow you to change e.g. user names, URLs or mail servers in a single place, directly affecting all existing automations.

J
Badge +2

I totally agree.

My take after having played around just a little bit: it would be really useful if there was some global key/value storage for the automations, which you could reference wherever in the configuration. Something just like workspace published parameters, in fact.

That would allow you to change e.g. user names, URLs or mail servers in a single place, directly affecting all existing automations.

So there are global key value pairs that you can assign, but they can only be used within the same automation, not across multiple unfortunately. The doc on that is here.

david_r
Rank
Userlevel 4

So there are global key value pairs that you can assign, but they can only be used within the same automation, not across multiple unfortunately. The doc on that is here.

Thanks, yes I've seen those. But it would be very useful to have some key/value pairs that you could use across multiple automations as well.

xiaomengatsafe
Rank
Badge +2

Thanks, yes I've seen those. But it would be very useful to have some key/value pairs that you could use across multiple automations as well.

Hi @david_r. Thank you for the idea. I can definitely see this being quite useful as well. Would you mind posting this as a new idea? And it would be great if you could elaborate a bit more on your usage scenario and needs, especially in the context of multiple users, and the management of these key/value pairs.

 

Thank you very much!

Reply


Community Stats

28,698
Posts
109,447
Replies
36,548
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.