Skip to main content
  • EN
I consider myself a veteran in spatial IT but newbie in using the FME tool - less than a year.

 

 

In my limited practice using FME, I increasingly feel the need to access "output ports" of Writers.  I saw some discussions dismissing such needs which for the most part I understood.  However, since ETL processes often times are synchronous in nature, picking up the "committed" results from database transactions for the following process will allow us to author fewer workspaces.

 

 

For example, feature elements of different types from ACAD files are extracted and processed before they are stored in several Oracle QC tables.  Without accessing the output ports of the QC tables just generated, I have to write a different workspace to Read from the tables for the subsequent process.  To piece automate the entire process in the sequence, I will need to use Python...

 

 

Any comments or advise is highly appreciated!

 

 

Bo

 

Hi Bo,

 

 

If I understand you correctly you want to chain translation/transformations.

 

For these cases I find the workspacerunner quite useful. By making use of it you can configure the second transformation (reading frorm Oracle QC tables) to take place only after the CAD features are processed and written.

 

 

This is just one of the ways (the most stright forward) for you to achieve that within FME.

 

 

Itay

 

 

Bo,

 

my thinking would be that, unless you've got some kind of trigger on the DB side that you need to run before you subsequently read the data back in, you shouldn't need access to writer output ports.

 

Given that you want access to output ports I'd say that you don't need them.  :)  If you get access to the writer output ports you'd be missing any results of triggers in your DB anyway.

 

Why can't you just route the features from the transformer immediately preceeding the writer and continue processing those features in your workspace? It's quite possible to route features from a single transformer to 2 seperate destinations. In your case one of these destinations would be the writer and another would be the first transformer of your continued processing.

 

Maybe I'm not understanding something here?

 

Nic
Hi Itay,

 

 

Thanks for recommending WorkspaceRunner which offers a clean ways to thread workspaces together.  I will give it a try.  Thanks!

 

 

Hi Nic,

 

 

I am not using any database triggers.  It is true that the features are from three different transformers that feed into my Oracle writers, which insert into three different Oracle tables.  I thought to have my sub-sequent process to be based on an Oracle view that combines the three tables. I could have processed based off the three transformers' outputs but I tought database view approach would be cleaner and more maintainable.

 

 

Bo

 

 

 

 

 

Hi Bo,

 

 

In such a case you can create the view, by routing the stream into a SQL executor, or inline querier.

 

That way you can continue processing and write the data all in one ws.

 

 

Itay 
Hi Itay and Nic,

 

 

I was able to use workspacerunner to piece the two ws together nicely! 

 

 

I tried to achieve the single WS solution.  I am not sure SQLExecutor could help as the sources were not SQL tables. 

 

 

I think I could use attributefilter and feature merger to get this work following Nic's suggestion, but the cost would be higher than the current two WS solution.  

 

 

Thanks!

 

 

Bo

Reply


Community Stats

30,159
Posts
114,480
Replies
37,805
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.