Skip to main content
Solved

logging FME Server job status at begin and end to Oracle Non spatial table

  • February 6, 2018
  • 2 replies
  • 18 views
annette2
Contributor
Forum|alt.badge.img+11

I have written an FME workbench hosted on FME Server that will be called by the Informatica application.

The Informatica team want a logging mechanism via an Oracle non spatial table.

 

The columns in the table are

workbench_id (published parameter filled by Informatica job call)

workbench_name (fixed value - e.g Clipper_Perf_POC)

run status (1 = run started, 2 = run success, 3 = run failed)

 

They want to insert a log message at the start and a second log message at the end of a workbench..

 

What is the most elegant way to do this - start up and shutdown scripts, fmeserverjobsubmitter (aka workspace runner)? Is it worth adding the fme server job id to the table...the workbench_id parameter filled by Informatica is not very informative for further investigation within FME Server.

Any tips would be appreciated.

 

Best answer by takashi

Hi @annette2, I would adopt an approach using the FMEServerJobSubmitter.

To the first workspace, add a process to insert the Job ID (and "workbench_id" if necessary) and the "run started" status to the logging table at first.

Then, create another workspace which contains a FMEServerJobSubmitter (Wait for Job Complete: Yes) to run the first workspace. To the second workspace, add a process to update the status of the record to "run success" or "run failed" according to result of the translation run by the FMEServerJobSubmitter.

I'm not sure whether it's elegant but I think the implementation is easier and also the maintainability is better than using Startup/Shutdown Python Script, in most cases.

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

2 replies

takashi
Celebrity
  • takashiCelebrity
  • 7843 replies
  • Best Answer
  • February 6, 2018

Hi @annette2, I would adopt an approach using the FMEServerJobSubmitter.

To the first workspace, add a process to insert the Job ID (and "workbench_id" if necessary) and the "run started" status to the logging table at first.

Then, create another workspace which contains a FMEServerJobSubmitter (Wait for Job Complete: Yes) to run the first workspace. To the second workspace, add a process to update the status of the record to "run success" or "run failed" according to result of the translation run by the FMEServerJobSubmitter.

I'm not sure whether it's elegant but I think the implementation is easier and also the maintainability is better than using Startup/Shutdown Python Script, in most cases.

Why not inspect features with Visual/Data Preview and Feature/Record Information before writing them into a destination dataset?
annette2
Contributor
Forum|alt.badge.img+11
  • annette2Contributor
  • Author
  • Contributor
  • 96 replies
  • February 12, 2018

Hi @annette2, I would adopt an approach using the FMEServerJobSubmitter.

To the first workspace, add a process to insert the Job ID (and "workbench_id" if necessary) and the "run started" status to the logging table at first.

Then, create another workspace which contains a FMEServerJobSubmitter (Wait for Job Complete: Yes) to run the first workspace. To the second workspace, add a process to update the status of the record to "run success" or "run failed" according to result of the translation run by the FMEServerJobSubmitter.

I'm not sure whether it's elegant but I think the implementation is easier and also the maintainability is better than using Startup/Shutdown Python Script, in most cases.

Many thanks Takashi. I am going to try this out this week

 

 

Community Stats

32,087
Posts
121,856
Replies
39,729
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.