Skip to main content
  • EN

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.

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!

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).

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.

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?

 

 

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

 

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

 

 

Reply


Community Stats

30,459
Posts
115,667
Replies
38,278
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.