My first experiment API+conditional workflow+iteration

Support
1

I submit my first experiment in which I have combined acquisition data via API, conditionally derived tables, and iteration + append results.
I would like any suggestions to improve the structure and the implementation of these projects.
In addition, I would need to better understand the relationship between the table “Case station.uid in” (inside the project Citybikes_05) and the result table of iterate+append action inside the project Citybikes_00.
Finally, I have one more question:
in the project Citybikes_00, I have implemented conditional workflow in order to circumvent some structural differences in the data pulled down via API, so Citybikes_05 produces two different outputs “Case station.uid in” and "“Case station.uid off”. Is it possible to integrate these two outputs in a single result table in the iteration step of Citybikes_00? If not, might you suggest the best way to manage analogous cases?CityBikes.zip (7.9 KB)

2

Hello Francesco,

Here are my suggestions:

  1. Instead of iterating another project, iterate a module in the same project.
  2. The "Tabular data" table is redundant because it only does a merge. The merge can be moved to the table from which "Tabular data" is derived and the group can be removed altogether.
  3. Having only one table in each table group maybe inconvenient as it may lead to too many groups. I would suggest merging groups "Station.uid in" and "Station.uid out" into one group "Result". Note that, if you just need a large table view you can always switch a table into the Analysis View which provides a maximized view of one table.
  4. When you do conditional branching, you would typically want to not repeat the same actions in each branch. Instead, when possible, move the same actions from both branched into the previous table, and keep only the actions that are different in each branch. This would simplify reading the workflow.

Yes, it is possible. In your case the conditional branching is mutually exclusive, meaning that the two branches can never be non-empty at the same time. Either one is empty (skipped), or the other. Therefore, you can use the "Either table" action to merge both branches into one table which will become the result of iteration.

An updated project is attached.
CityBikes_00_DG.morph (13.7 KB)