Looking for general guidelines for successful step-looping, as I’m unable to use the looper widget in my current LTS 8.2 private cloud Tulip instance.
I’m getting some strange behavior wherein the “Step Enter” instructions don’t seem to be firing on the return to the first step in a two-step loop. This is manifesting as follows: the loop action to unlink table records is occurring, but the subsequent refresh of the multiselect representing the still-linked records (so they can be selected to unlink them, if still in error) is still showing the values that were already unlinked. The multiselect widget is not refreshing, but the table record widget is. If I run the loop again, it refreshes. Looping is based on Array Length >0, so I feel like maybe I need another Loop Count variable to start as Array Length +1 and run down to zero to get the extra loop, but I’m still not sure why that would be necessary. I can add screenshots later if anyone needs more detail, but really just looking for generic guidelines / best practices for step-looping.
Hey James - got some thoughts from the team on this one:
The main advice is to try and avoid using the looper widget due to GxP concerns. Some other options / suggestions are:
Try to loop without the widget - just use an on-step enter trigger and manipulate some variable/array until the “end loop” condition is met.
Since this is a table record heavy app - next question would be, could we consolidate it and/or use completion records to eliminate the need to link and unlink multiple table records at once?
Hey @mrios92 - Thanks for asking for clarification!
The main concern is that the looper widget uses a custom code and falls “outside” the standard validation for the Tulip platform. A GxP customer can still choose to use it, but it requires validation on that code and would complicate validation. This holds true for any custom widget that isn’t part of a standard LTS deployment.
From the loop origin step, in button triggers, get the length of the array containing the elements on which the loop acts, then if the length is >0, transition to the loop action step.
In the loop action step, I use an On Step Enter trigger (just one trigger) which acts as follows:
as long as the array length is >0, remove from index 0 of the array and store in a placeholder variable, recalculate the array length, then act on that variable (e.g. load record, or add to an object or array), then transition back to the start of the loop transition step (I currently prefer this vs. going back and forth between two steps as it allows for more array elements to be processed, i.e. ~100 vs 50).
Once the array length decrements to 0, the trigger Else If sends you instead to your loop destination step (which could be the origin step or another step), or you can just have it stop at the loop action step.
Another odd thing I’ve observed, if I have extra disabled triggers on the loop action step, they get counted against the 100 triggers limit. Not sure if that is an LTS8.2 issue only or still persists.
I guess there is a need to the sthe acutal triggers (including the order) to investigate this further.
I had an issue, where I manipulated a multi select list with a custom widget and the list was not updated correctly as well. It turned out, that the reason was a wrong order of the triggers.
@mrios92 The main concern with Custom Widgets and GxP is that currently Custom Widgets lack versioning. We have plans to implement versioning in the future, but at this time it is not available. As long as you are comfortable managing your custom widgets without a native versioning solution then there is no technical issue.