Skip to main content
Question

FME Server summary when running workspace


Forum|alt.badge.img+6

When running a workspace on FME Server, you get a summary as to whether the workspace completed successfully and how many features were written. However not all workspaces end with a writer, so this information is not always valuable/relevant. You then have to browse through the log details to inspect whether you got the desired results.

A perfect scenario for when this happens is when you have workspaces that call REST APIs. I would like a way to return the response or error from a workspace. Regardless of the response, FME Server reports that the workspace completed successfully, but that doesn't mean I got the desired result. For example all is good if I get a 200 back, but if I get a 400/403/404 etc., then I would want to see that clearly without having to go through the logs. Is there a way to customize this summary? It would be great if one could easily define the attributes etc. in the workspace that you want to be visible in the summary screen. Thanks.

6 replies

Forum|alt.badge.img

Hi @dbaldacchino,

a quick & easy way to create a failure for 4xx response codes of REST APIs could be a Tester that checks the response code and whenever it's a 4xx you route it to a Logger to write the info to the log file and then to a Terminator. The Terminator will make sure the workspace fails and is not displayed as successful.

Hope this helps!


Forum|alt.badge.img+6

Thanks @GerhardAtSafe, I'll give that a shot. Should the Rejected Feature Handling also work in this case? I'm finding that on FME Server, I don't get the same behavior as in Workbench (2017.1).


Forum|alt.badge.img+6

This will improve things a bit, but you still have to go through log files to understand what happened. For users, these tend to be too verbose so I was hoping I could show a succint result in the summary screen (similar to the number of features written for example when a writer is used). In my case I didn't need to use a tester as I can just log the <rejected> port directly.


Forum|alt.badge.img
dbaldacchino wrote:

Thanks @GerhardAtSafe, I'll give that a shot. Should the Rejected Feature Handling also work in this case? I'm finding that on FME Server, I don't get the same behavior as in Workbench (2017.1).

Yes, you can also route the rejected features directly to the Terminator to stop the translation. This should catch most HTTP errors and is even easier than my previous suggestion. The behavior should be the same on FME Server & FME Desktop though. Do you have an example of the difference?

 

 


Forum|alt.badge.img+6
gerhardatsafe wrote:
Yes, you can also route the rejected features directly to the Terminator to stop the translation. This should catch most HTTP errors and is even easier than my previous suggestion. The behavior should be the same on FME Server & FME Desktop though. Do you have an example of the difference?

 

 

@GerhardAtSafe I am using an HTTPcaller. In Workbench the workspace terminates as expected when features come out of the <rejected> port but the behavior is not the same on FME Server. If I add a Terminator, then I get the expected result. I have also posted a separate question here: https://knowledge.safe.com/questions/65274/rejected-feature-handling-on-fme-serverf.html

 


Forum|alt.badge.img
dbaldacchino wrote:

This will improve things a bit, but you still have to go through log files to understand what happened. For users, these tend to be too verbose so I was hoping I could show a succint result in the summary screen (similar to the number of features written for example when a writer is used). In my case I didn't need to use a tester as I can just log the <rejected> port directly.

I agree this could be still improved. This is idea seems to match with what you are looking for. Feel free to vote for it or an add a comment with some details of your requirements:

 

https://knowledge.safe.com/idea/22530/rejected-features-summary.html

 

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings