It might be best to post a screenshot because its hard to get a true understanding of the actual configurations?
But if you have two httpcallers, and go out to one featureholder and terminator(s), the termination will occur before a feature gets released from the featureholder. This is the easiest.
If they are instead two httpcallers and going to two seperate featureholder then you run the risk oof one featureholder letting go. But there are numerous options that could be used in this instance, such as making sure the writer order to the database was set after something else, that would write only when things are correct. Or instead of the featureholder, you could use the featuremerger with something uncondtional (e.g. 1= 1), passing the httpcaller output to the requestor and both the rejected ports from the httpcallers to the suppliers. If a record merged you would terminate, while not merged could write to the database
It might be best to post a screenshot because its hard to get a true understanding of the actual configurations?
But if you have two httpcallers, and go out to one featureholder and terminator(s), the termination will occur before a feature gets released from the featureholder. This is the easiest.
If they are instead two httpcallers and going to two seperate featureholder then you run the risk oof one featureholder letting go. But there are numerous options that could be used in this instance, such as making sure the writer order to the database was set after something else, that would write only when things are correct. Or instead of the featureholder, you could use the featuremerger with something uncondtional (e.g. 1= 1), passing the httpcaller output to the requestor and both the rejected ports from the httpcallers to the suppliers. If a record merged you would terminate, while not merged could write to the database
Hi @todd_davis fortunately I let both HTTPCallers share one single FeatureHolder and one single Terminator, so seems the termination will always occur first. Do you know whether there is some FME help/manual document that I can use to justify this directly or indirectly? Thank you!
Below is a diagram of the configuration.
Hi @todd_davis fortunately I let both HTTPCallers share one single FeatureHolder and one single Terminator, so seems the termination will always occur first. Do you know whether there is some FME help/manual document that I can use to justify this directly or indirectly? Thank you!
Below is a diagram of the configuration.
The FeatureHolder's documentation should say that it only releases features when every transformer that is upstream (ahead of it and connected, directly or indirectly, to it) is completely done its work. FME works to push every feature as far as it can before going back and trying to get the next one to work on. So, if any HTTPCaller should reject a feature, that would happen *before* the HTTPCaller would tell any downstream Transformers that it is done its work. And since each transformer pushes any feature it emits as far as it can before it tries to emit any other, or before it tells anyone downstream it is done, the graph you've drawn will do as you want. Nothing could ever get out of the FeatureHolder unless the HTTPCaller(s) complete without any problem.
I'll alert the doc team to this and see if we can explain this better somewhere. This is a great example.
The FeatureHolder's documentation should say that it only releases features when every transformer that is upstream (ahead of it and connected, directly or indirectly, to it) is completely done its work. FME works to push every feature as far as it can before going back and trying to get the next one to work on. So, if any HTTPCaller should reject a feature, that would happen *before* the HTTPCaller would tell any downstream Transformers that it is done its work. And since each transformer pushes any feature it emits as far as it can before it tries to emit any other, or before it tells anyone downstream it is done, the graph you've drawn will do as you want. Nothing could ever get out of the FeatureHolder unless the HTTPCaller(s) complete without any problem.
I'll alert the doc team to this and see if we can explain this better somewhere. This is a great example.
Hi @daleatsafe what I have may become the diagram below, the AttributeCreator before the Terminator is not at "upstream" of FeatureHolder. In this situation is there a chance for feature get out of FeatureHolder first?
Thank you!
Hi @daleatsafe what I have may become the diagram below, the AttributeCreator before the Terminator is not at "upstream" of FeatureHolder. In this situation is there a chance for feature get out of FeatureHolder first?
Thank you!
Very good question. The AttributeCreator is NOT a blocking transformer, so it will send its feature through to the Terminator BEFORE it tells the HTTPCaller that it is done. If instead you put a FeatureHolder (or any other blocking transformer) BEFORE the Terminator, than that transformer would tell the HTTPCaller it is done BEFORE the Terminator got the feature. And in that case, it is undefined whether the Terminator would get control before the other FeatureHolders let loose.
Hope this helps.
Hi @daleatsafe what I have may become the diagram below, the AttributeCreator before the Terminator is not at "upstream" of FeatureHolder. In this situation is there a chance for feature get out of FeatureHolder first?
Thank you!
Hi @daleatsafe thank you for your explanation, then I am more confident that the FME workspace should terminate as I expect. Is the "push every feature as far as it can before going back and try to get the next" philosophy of FME already documented somewhere? or this is what you alerted doc team to add?
Thank you!
Hi @daleatsafe thank you for your explanation, then I am more confident that the FME workspace should terminate as I expect. Is the "push every feature as far as it can before going back and try to get the next" philosophy of FME already documented somewhere? or this is what you alerted doc team to add?
Thank you!
Yes, this is what I asked for from the doc team.
