Your question is not very clear. FME always works sequential, essentiallly letting the data flow from left top right, feature by feature. You say you have an sql executor which gives you the result in your screenshot, so when you attach other transformers to the results-port of your sql executor, those transformers will work on each row in turn. No need for looping constructions or anything.
so that each is fully processed before the next one starts
What do you mean by fully processed? What processing needs to happen? And why would it be a problem if the first is not entirely finished when the next one starts? If it’s only 5 rows like you show here, it’ll be done before you can blink...
attribute I’d like to pass one by one
What do you mean by this? Pass where? Hand it over to a webservice? Insert it into another table?
If you can explain a bit more about what you have and what you are trying to achieve, we can give you better assistance. For me this is too confusing right now.
@s.jager , what I mean is that I want the result from the sql to be processed one at a time. So, when looking at the screenshot I sent above, I want device_id 53512 to be fully processed to the end of the workbench before the next one (device_id 47320) begins being processed by the workbench. I hope this is a little clearer.
thanks
I still don’t understand why you would want to do that? That’s only going to slow things down tremendously. And to be honest, I’m not even sure you can do that in a single workspace.
You could possibly achieve it using a workspace runner, where you have your first workspace get the rows you need to process, then create another workspace that processes only a single row based on the unique key. Then use a WorkspaceRunner in the first workspace, calling the second one, and making sure that you set Wait for Job to Complete to Yes, probably also set Maximum Concurrent FME Processes to 1. That way you are sure that there is only ever one workspace processing your rows, without the need for looping. Of course you can use looping, but I still don’t see why you’d want to go through all this trouble. For 5 rows this won’t be much of a problem, but if you have to process a 100.000 this will seriously impact your performance.
I fully agree.
You state twice that you want to process the features one by one, but why do you want that? Can you share your reasons for that wish?
Does the processing of device_id 47320 depend in some way on the successful processing of device_id 53512? If not, then there seems to be no reason for processing the features one by one.
@fbastian73 to similarly comment, one core FME concept is that the workspace does not use “tables” of data. This is confusing to many new users who are use to dealing with Database Tables or Queries/View etc.
Each Feature is its own individual element. FME, by default, processes each Feature one-by-one in sequence rather than as a whole table.
There are exceptions in some bulk mode enabled Transformers, but if you are passing the Features to say a downstream SQLExecutor, or many forms of the FeatureWriter etc. these will generally by default not process the next Feature, until it has first finished processing the current Feature.
Apart from that, sequencing/iteration of operations is generally only required if the output from processing the next Feature has a dependency on the output from the processing of the previous Feature. If the operations are instead independent then it doesn’t matter if processing operates sequentially or in parallel.
There is a halfway solution, if consider using a Decelerator transformer if the requirement is to throttle the data throughput say to a downstream system that may otherwise become overwhelmed, although most modern enterprise systems now have built-in traffic control to stop these kind of Denial-of-Service type data flooding to not need further controls from the user process transmitting the data.