Now I run into the situation that I have a master table (for villainous plans ) that returns one master idea / plan.
Based on this plan or category the workflow will run through different substreams with different resulting tables.
E.g. if a villainous plan is to destroy a certain community, then I also want to go through the subflows for
Which community
Why this community
How will the villain do it
Other plans might be something like âvandalismâ or " economic advantage" which may result in completely different substreams than the 3 mentioned above.
My immediate thought was to use case switch but this comes with several challenges:
Not all substreams will return the exact same columns
I would either need to chain Case Switches or would need 1 Case Switch with 15 outpostsâŠ
Hi @kowisoft , in order to answer this, we would need to know whatâs on the downstream of these 15 Cases. What are the differences? Are the actions different, or is it only values to be used are different?
If actions are different, can they be regrouped? For values that are different depending on the case, you can use a table and use join.
We would need to see what the workflow is doing down the road.
From what I see, the action is pretty much the same for the 3 sample cases:
1- Row Filter
2- Append columns from another table
Obviously with 3 cases, itâs OK to proceed this way. For 15 cases, it looks like it could be configured dynamically.
Just an idea off of my head, you could define the row filter rules in a table for each of the 15 cases. For the appended columns, itâs a bit more tricky, depending on how many rows you have, but still doable. You would still need to create all of these columns somewhere - either in a Table Creator, or read from a file. The trick would be the naming convention where the selection of the columns to append would depend on their names.
Again a very interesting and challenging question !
Sorry Iâm replying from my smartphone and hence away from a computer so I cannot provide a workflow example.
Nevertheless the first generic idea that comes to my mind is to implement everyone of your Case-Switch options as a subworkflow and then call the right subworkflow based on its name in a variable. This would allow to easily implement a Generic-Dynamic-Case-Switch component of as-many-as-needed cases.
The number of rows is always limited, itâs usually just one row with a varying number of columns and headings. As the row filter is only for this example, usually the whole dice sim thing is a little bit more complex, but I didnât want to blow up the example.
Right @kowisoft, this is how I would do it because as far as I know this is the only âfunctionalâ way of calling a piece of code in KNIME. By âfunctionalâ call I mean âpassing a function as an argument when using a nodeâ and this is what you need to create a âgenericâ Case-Switch implementation with a variable number of case-switches and their associated âactionsâ.
Every possible âactionâ would be implemented as a call by variable to a local workflow where the variable wiuld indicate its name among different possibilities that you would need to case-switch.
@kowisoft Each villain seems to have a completely distinct path, so I would take a rather different approach. I would start with a table with all the VillainNames, the VillainGoals and all the possible questions, like this one
I somehow got a result, but I really donât understand how KNIME deals with JSON (Iâm not a JSON expert at all). I recognize the table structure and how it is displayed in a JSON-way, but I simply do not understand how I could apply this to my example workflow.
The columns are always different and I always get back all results, which is not what I want.
Are you essentially trying to accomplish conditionally splitting rows into 15 different outputs so that you can process them all differently? Like a conditional multi-router?
If so, then I have built something like this in Alteryx in the past. Never tried to see how many outputs KNIME will allow on a component thoughâŠ
Itâs either the other way around. I have a table with 15 rows. Then I apply a dice simulator and based on the result of throwing that die, 1 row will remain. But it can be any of the 15 from the original table.
And based on the remaining row, you will have to execute some sub worklfows.
I think I have it somehow working right now and might publish my results here soon.
@kowisoft I thought my workflow could work because it outputs the same results as your example. Iâve worked on some ideas on the development of plots based on alternative choices. The following workflow is an example of how it could work
if we select action âalt2.1â this is the componentâs output
Perhaps this workflow may be of some interest to those dealing with âpotential literatureâ, following the example of the OULIPO. It would be interesting to explore (more seriously) the possible applications of Knime in this field.
Attention: If you want to download it, make sure to also download the folder subs including the 2 workflows sub1 and sub2
Looking at my final result, I must admit that my example was not the best one, because it leaves the impression, that the villain (in this stupid example) is the driver. But looking at the solution - the Villainâs Goal - is in the end what drives which sub-workflow is executed.
If you consider this, in the examples above you could e. g. choose either âThe Jokerâ or âDoc Ockâ and get different results, driven by the goal.
Thatâs also what my main goal in my adventure creator workflow is. The idea there is that you have a master table with 15 different villainous goals (such as âEconomic Powerâ or âDestroy Good-Aligned Groupâ and then - based on this âcategory decisionâ from the master table, you will derive the sub workflows and their âadditionalâ columns.
Sometimes itâs just 1 additional column, sometimes moreâŠ
I know that this is - once again - kind of a nerdy use case, but I am pretty one could translate this into business purposes as well - e. g. think about extracting assets including their asset classifications from an ERP system and then - based on the asset class - do different calculations.
I really hope these nerdy ideas help more people than just me
Sorry Iâm replying late to your posts and questions about the JSON implementation since it is only now I have access to a computer with KNIME.
The good news is that you got the idea and managed to implement it eventually !
I had a look at your solution and it could be implemented in a simpler way just by using the -Call Local Workflow (Table Based)- and the -Container Input (Table)- nodes. I do not think one needs the JSON versions in your case although it is a very good example illustrating how to use them too.
Using the -Call Local Workflow (Table Based)- and the -Container Input (Table)- nodes, you would not need to go through JSON settings and conversions as in the solution showed here below :
This illustrates how a generic CASE-SWITCH scheme controlled by a variable could be implemented with as many switch options as sub-workflows needed for that.
Again, @kowisoft you posted here a very nice challenge !
) that returns one master idea / plan.
)
