Question

Email Data Download URL in FME Server Apps

  • 6 November 2019
  • 3 replies
  • 28 views
G
Badge

When running long jobs, the ability to provide an email address for sending a download URL to is very convenient. Unfortunately, this only seems to be provided with 'normal' jobs and not within a FME Server App.

I did some searching and encountered this Idea (click). Of course I voted for this, but that will not help me out on the short term.

I looked into modification of the notification message (e.g. using FMEServerNotifier transformer), but this does not appear to be possible. I would really like to stay away from solutions like chaining workspaces in Automations or using the emailer Transformer. Better would be to use the already available functionality for notifications.

Anyone some ideas about fixing this?

3 replies

J
Badge +2

Hi @g_karssenberg

 

 

Currently we don't have any plans to implement this into FME Server apps, but thank you for voting and providing more context on the idea you linked.

 

 

I think the easiest way to do this would be to set up your app to run a workspace that uses a HTTPCaller to call the intended Data Download workspace (you can see how to do that here: https://docs.safe.com/fme/html/FME_Server_Documentation/ReferenceManual/service_datadownload.htm). As long as you set the opt_servicemode to sync (so it waits for the job to finish) then in the HTTP response you should get the Data Download URL returned to you (also in the linked doc).

 

 

You can then create the email that you want to send to the app user (you'll need to add a published parameter asking them for their email address) - and you should be able to send the email in whichever way is easiest for you: emailer/email subscription.

In case your users may wait long enough to download the results from the browser, you could set the app workspace up to be a Data Streaming workspace, that returns a HTML page including the Data Download link (returned from the HTTPCaller). If you're not familiar with HTML, our HTMLReportGenerator makes it easy to create a web page without any coding.

 

 

I'm sorry that the FME Server Apps don't have the 'email results to' option, but hopefully the above provides a workaround that can avoid chaining workspaces in automations and use the notification service rather than the emailer transformer.
G
Badge

Hi @g_karssenberg

 

 

Currently we don't have any plans to implement this into FME Server apps, but thank you for voting and providing more context on the idea you linked.

 

 

I think the easiest way to do this would be to set up your app to run a workspace that uses a HTTPCaller to call the intended Data Download workspace (you can see how to do that here: https://docs.safe.com/fme/html/FME_Server_Documentation/ReferenceManual/service_datadownload.htm). As long as you set the opt_servicemode to sync (so it waits for the job to finish) then in the HTTP response you should get the Data Download URL returned to you (also in the linked doc).

 

 

You can then create the email that you want to send to the app user (you'll need to add a published parameter asking them for their email address) - and you should be able to send the email in whichever way is easiest for you: emailer/email subscription.

In case your users may wait long enough to download the results from the browser, you could set the app workspace up to be a Data Streaming workspace, that returns a HTML page including the Data Download link (returned from the HTTPCaller). If you're not familiar with HTML, our HTMLReportGenerator makes it easy to create a web page without any coding.

 

 

I'm sorry that the FME Server Apps don't have the 'email results to' option, but hopefully the above provides a workaround that can avoid chaining workspaces in automations and use the notification service rather than the emailer transformer.

Hi @jlutherthomas,

Thanks for your reply.

I get the point of your suggestion to use a HTTPCaller. This should work, however then we would need a 'runner' workspace for each FME Server App. That would not be ideal but I will take this into consideration.

I think that your suggestion of the Data Streaming option is not relevant, because also with FME Server Apps the user will get the download URL returned on the screen if the app uses this service. This part works perfectly fine. However, the user would have to keep the screen open and for long processes this is not desirable. With a 'normal' run (logged in the FME Server web interface) this is possible.

You say that currently you don't have any plans for providing this option for emailing, but I really see this as a major downside for using FME Server Apps compared to a 'normal' run.

virtualcitymatt
Rank
Userlevel 4
Badge +26

I see this is still and issue.

 

Just sharing a solution which is less than ideal, however, it does remove the need to an additional engine to be used as a 'runner'.

Create a separate workspace which is subscribed to both failure and success DataDownload topics for the workspace. Set up a workspace subscription to parse the json of the response -This will include the download link and the job status.

 

The email address must be added to the App workspace - you can get the email by using a REST call to get the completed job result. The job ID will be in the Topic content.

 

Now that you have the Email address and DataDownload link you can just use an Emailer Transformer.

 

This method has it's pros and cons - Pros include being able to send other info from the published Parameters in the email and it doesn't tie up an extra engine for a long time. It can also be made somewhat dynamic depending on the workspace run. You can configure the email content to be dependant on the workspace name and then only have to have one workspace which replaced the SMTP notification

 

Downsides are that you can't use the email template language.

 

 

Reply


Community Stats

28,681
Posts
109,409
Replies
36,542
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.