Skip to main content
  • EN

I have created a custom looper transformer and embedded the saved FMX file. I may be (probably) doing something wrong or missing one key terminator of the looper but if I set the MAX ITERATIONS manually, the results work perfect.

For example, I am running a loop that calculates the cumulative effect of the data monthly meaning that I send the results of the sample out as well as loop them back in. Again, I have this part working perfect but I can't stop the machine at the end programmatically. Either skynet is learning or I screwed up.

I can set the MAX iterations via a published parameter and it does work as expected, but when I hand this over to a less diligent client I foresee trouble. If they want to run it iteratively for 3 years (of the dataset), they have to manually enter a max iteration count of 36 (it's setup in months right now.)

I do have a calculated max column so if I could somehow set this via an attribute, all would be well.

Any thoughts?

FME 2016.0.1 Build 16174. I have tried on both OSX and PC to no avail.

That is odd. I've never used it the way you do, but it should work right?

As a workaround: if the (looping part of your) transformer does not contain any blocking transformers (e.g. FeatureHolder, FeatureMerger etc.), you can set the "Enabled blocked looping" property to "No" and then break out of the loop yourself.

 

Just add a Published Parameter the way you normally do (either by adding it in the nav panel or by exposing/adding an attribute on the Input port) that will hold the max iterations, e.g. MAX_ITER. Then add an AttributeCreator/Manager right after the Input port that will set an iteration count attribute (e.g. _iter) and give it a value of 0. Right before the features enter the Loop port, add a Tester that will check if the _iter attribute is equal to $(MAX_ITER). Connect Passed to the Output port/branch and Failed to the Loop port. Finally, add an AttributeCreator/Manager within the loop that adds +1 (or whatever your step size is) to the _iter attribute.

You should now be able to set the max iterations through another Published Parameter in your main workspace (or even an attribute!).

That's interesting. I'll file a request with our developers as I don't see why that couldn't be set as an attribute.

I see another option is to "Open Text Editor". Could you pick it from the attribute there? ie use @Value(<AttributeName>)

That is odd. I've never used it the way you do, but it should work right?

As a workaround: if the (looping part of your) transformer does not contain any blocking transformers (e.g. FeatureHolder, FeatureMerger etc.), you can set the "Enabled blocked looping" property to "No" and then break out of the loop yourself.

 

Just add a Published Parameter the way you normally do (either by adding it in the nav panel or by exposing/adding an attribute on the Input port) that will hold the max iterations, e.g. MAX_ITER. Then add an AttributeCreator/Manager right after the Input port that will set an iteration count attribute (e.g. _iter) and give it a value of 0. Right before the features enter the Loop port, add a Tester that will check if the _iter attribute is equal to $(MAX_ITER). Connect Passed to the Output port/branch and Failed to the Loop port. Finally, add an AttributeCreator/Manager within the loop that adds +1 (or whatever your step size is) to the _iter attribute.

You should now be able to set the max iterations through another Published Parameter in your main workspace (or even an attribute!).

Thanks @sander_s. I'll give this a go...

The other way would be to put the calculations for max column inside a scripted parameter and use that. Of course, it wouldn't be able to access attribute values, which might be a problem here.

That's interesting. I'll file a request with our developers as I don't see why that couldn't be set as an attribute.

I see another option is to "Open Text Editor". Could you pick it from the attribute there? ie use @Value(<AttributeName>)

Filed as PR#68350 - but I'm not confident it's something we could do (or that any workaround I suggest would work)

Filed as PR#68350 - but I'm not confident it's something we could do (or that any workaround I suggest would work)

Seeing as FME delivers in so many other ways, I'm content allowing the client to manually enter the number :-)

Yes, some type blocking transformer do allow it others don't..

Always thought that was strange.

But you can overcome it with a scripted parameter by putting the blocking transformer in a normal custom transformer.

The scripted parameter parameters need to be parameters.

These are then accesible trhough the normal "wrapping"customtrnasformer.

Like this:

itnf-max-it-setup.png(404.2
kB)

where wrapper is

Yes, some type blocking transformer do allow it others don't..

Always thought that was strange.

But you can overcome it with a scripted parameter by putting the blocking transformer in a normal custom transformer.

The scripted parameter parameters need to be parameters.

These are then accesible trhough the normal "wrapping"customtrnasformer.

Like this:

itnf-max-it-setup.png(404.2
kB)

where wrapper is

Hey @gio You're absolutely right custom within custom essentially turns the attributes into parameters.

However, I can't seem get the number to stick. For instance, I am running the tool on one year. The calculated number of months is correct at 12. I even ran a StringFormatter and forced it to d (INTEGER.) However, when I set the parameter to the the MaxIterations as the Months value (which I confirmed enters as 12) it perpetually loops. If I manually set it to 12, it outputs correctly.

Not sure if you've run into this before but it feels like either there is a bug or I'm doing something wrong...

That is odd. I've never used it the way you do, but it should work right?

As a workaround: if the (looping part of your) transformer does not contain any blocking transformers (e.g. FeatureHolder, FeatureMerger etc.), you can set the "Enabled blocked looping" property to "No" and then break out of the loop yourself.

 

Just add a Published Parameter the way you normally do (either by adding it in the nav panel or by exposing/adding an attribute on the Input port) that will hold the max iterations, e.g. MAX_ITER. Then add an AttributeCreator/Manager right after the Input port that will set an iteration count attribute (e.g. _iter) and give it a value of 0. Right before the features enter the Loop port, add a Tester that will check if the _iter attribute is equal to $(MAX_ITER). Connect Passed to the Output port/branch and Failed to the Loop port. Finally, add an AttributeCreator/Manager within the loop that adds +1 (or whatever your step size is) to the _iter attribute.

You should now be able to set the max iterations through another Published Parameter in your main workspace (or even an attribute!).

Hi @sander_s. I took another stab at your approach and it seems to work. So I'm going to claim victory over this workbench and not fuss with it anymore! Thanks to @gio and @Mark2AtSafe for the input so far on this!

Reply


Community Stats

30,352
Posts
115,344
Replies
38,086
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.