As a rule, model elements execute in sequence rather than concurrently, so when 2 elements are linked by a flow (say Write Supplier Record's exit and Extract Spreadsheet Rows' exit) , the one at flow's target (Extract Spreadsheet Rows' exit) will not start execution until the one at flow's source (Write Supplier Record's exit) finishes execution (= all instances of the repetition). This also means that what is actually output by Extract Spreadsheet Rows' exit is the output of the last instance of Write Supplier Record, but this is of no consequence in our case, as we don't really need the record, and we're just using flow to determine order of execution, which is why the triggers on Close Window and Refresh Supplier List are Control triggers which are of Nothing type, meaning they do not pass values of any type. In fact in stage 13 we provide an alternate method (for the source), using a <Done> exit whose sole purpose is to determine order, by activating flows without passing values.
You ask what executes next, given that Close Window and Refresh Supplier List are both dependent on flows whose source is the same. The answer is that we cannot know by looking at the model, in reality execution order in such cases is determined by the order in which the relevant elements, models and flows, were added to their parent. Strictly speaking it would not be a bad idea to order these elements explicitly (by making Close Window dependent on flow coming from Refersh ...) making the model flow explicit, but there's no actual need to do so, as a logical representation of the display being closed is maintained in memory for as long as any part of processes/flows in that display are active. Note that there is one case where it is required making the order explicit (= ensuring Close Window is the last plugin executed), which is the case when a File Input Field is included in the closed display, due to the browser security model.
I recommend you get acquainted with visual debugging (a.k.a trace), which allows you to view the order of execution visually and dynamically.
I agree that these issues do merit a mention in the tutorial. Thanks for pointing this out.
And if I missed anything or raised new questions, you're more then welcome to respond with a followup.
Regards,
David
To use the full functionality of this web site, JavaScript needs to be turned on.
For best results, use the Firefox browser..
Copyright © 2003-2017 - Tersus Software Ltd., All rights reserved. Terms of Use License Graphic design by EmaraDesign