Hi
I'm working on a project where we are migrating from a solution based on subscriptions into more automations. I ran into problems when I try to pick up the topic name from fme server parameter FME_TOPIC. Inside a workspace triggered by a subscription all is fine, but when a use automation with a FME Server Topic Trigger, the value of FME_TOPIC is a GUID like string. First part of is the same as the automation id. I have no problem with FME_TOPIC_MESSAGE parameter. Any ideas?
Thanks, Stefan
+7
Hi @stlj, this is a bug in FME Server that has been shared with the development team. Unfortunately, we do not have a REST API that can return the topic name for a provided topic ID.
+4
Are there any workarounds?
The only thing I've come up with is to use multiple trigger (one per topic) and set a user key with a different value on each one. The key can then be passed to a parameter in a workspace.
+7
Are there any workarounds?
The only thing I've come up with is to use multiple trigger (one per topic) and set a user key with a different value on each one. The key can then be passed to a parameter in a workspace.
@jwarren after speaking to the development team, it does not appear there is a workaround. If you can share more about your workflow and what you're using the topic name for, we may be able to suggest an alternative.
+4
@jwarren after speaking to the development team, it does not appear there is a workaround. If you can share more about your workflow and what you're using the topic name for, we may be able to suggest an alternative.
I have a workspace to generate a report based on data from an application. When a particular topic is notified, the a draft version of the report is built, but when a different topic is notified, the final version is generated and all drafts deleted. In other words, I'm using the Topic name as a switch for the behaviour of the workspace.
My work around is to use two triggers in the Automation, one for each topic. Each trigger sets a user key (with a different value), thereby allowing me to tell which topic triggered the automation. The user key is passed to a user parameter in the workspace.
It's not a particularly scalable model, but it works for a low number of topics.
+7
@jwarren after speaking to the development team, it does not appear there is a workaround. If you can share more about your workflow and what you're using the topic name for, we may be able to suggest an alternative.
I see, thanks for sharing!
There are probably many different ways to solve this, but I would consider a webhook trigger instead. Then you can submit a POST request to the webhook trigger's URL using the HTTPCaller, passing in the document status in the JSON body. You can expose the output attribute from the JSON body by clicking Import Parameters from JSON and pasting in a sample JSON body from your HTTPCaller. The output attribute can then be passed into your workspace.
(Make sure the Automation is running or you won't be able to communicate with the webhook trigger)
+4
@jwarren after speaking to the development team, it does not appear there is a workaround. If you can share more about your workflow and what you're using the topic name for, we may be able to suggest an alternative.
Yeah that could work. In a very similar vain, I also played around with putting a parameter into the notification message: I felt it made the workspace which is creating the notification less readable.
It is also helpful to be able to enable and disable the topics independently, particularly during testing.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
