Better alternative to CASE SWITCH (with 15 options)?

Hi my dear KNIMErs,

Is there a better way than a CASE SWITCH combo if I have 15 options?

Let me explain:
I am currently in the process of building me an (procedural) adventure creator using KNIME (see also this question here: Take row content from a row if the column index = iteration number )

Now I run into the situation that I have a master table (for villainous plans :smiling_imp:) 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:

  1. Not all substreams will return the exact same columns
  2. I would either need to chain Case Switches or would need 1 Case Switch with 15 outposts…

How would you suggest to solve this?

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.

Thank you @bruno29a

I uploaded an example workflow to the hub (completly left out the randomness / dice mechanic, as it might not be relevant here)

Thanks for the workflow @kowisoft .

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.

Hi @kowisoft

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.

Hope it helps :blush:

1 Like

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.

Interesting, do you mean by the “Call Local Workflow” Node? That would be in general a neat way to design this whole thing.

So far I have worked a lot with components (and components within components that is :wink: )

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.

Hope it helps :wink:

Hmmm… I tried to play around with it but I just can’t seem to understand how this would help?

Maybe it’s the returned JSON code. Why would I need that?

@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

and I would select the goal at the end of the workflow. Something like this

20220508_villaingoals.knwf (21.4 KB)

Thank you for the feedback @duristef … Unfortunately this doesn’t work because the goal would determine what comes next in my real use case

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…

1 Like

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.

1 Like

Now I get it. I am interested to see where you are going with this…

@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

The “Select a new step” component can be configured
and executed. This is the output of the first one, given the choice shown above

A different choice would produce a table with a different structure

I added two tables, with dummy values, just to represent

  • a possible development (upper join)

    which can be filtered by the subsequent component. e.g.
  • a plot involving agents discarded by the choices selected in Action 2 (lower join) and the alternative actions they can take

    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.

Here’s my solution:

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 :slight_smile:

Same result from the first component of my workflow. If you select

you get


Hi @kowisoft

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 :wink: !

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 :

The subworkflow would be also modified from:

to a simpler solution too :

I’m posting here for reference the modified main workflow with the two alternative sub-workflows too:

20220508 KOWISOFT main workflow.knar (205.3 KB)

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 :wink: !

Hope it helps,



That is very nice @aworker … wasn’t aware of that (because I was too lazy looking for another Call Workflow node.

Thank you so much (and all the others) for providing this many feedback for some kind of nerdy stuff. :slight_smile:

1 Like