Concatenate cell/variable values to itself

[roberting]

Hello all,

this is my task and I do not know how to go about it:

my table has a number of columns containing different measures (diameter, thread size, length, etc. which are also the column headers)

each row is a product that is described by these measures. However, different types of products have different measures, so that some have a diameter, others don’t, but may have a thread size and/or length instead.

I want to create classes of products (or product models) by checking which measures they use (and which ones not), i.e.:

• if diameter and length are present (but no thread size) → this must be a tube
• if thread size and length are present → this must be a screw
• if diameter and thread size are present → this must be a fitting

my idea was to create a class name string for each row (product):
if a columns contains a value, then concatenate the respective column name to the string (itself) and put that newly created string in a new column called product_type. referencing the example above, something like:

for the tube the string would read “diameter_length”
for the screw the string would read “threadsize_length”
…

I tried that with a Column List Loop node and string manipulation, but the result when the loop is done is always only the last string, not the concatenated one:

In this example I do not check wether cells are empty or not, it is just the “dry run” to check the concatenation, but it does not work.
(I also tried this in a similar fashion with “String manipulation (variable)” to write back into a source variable instead of a cell, but this also included only the last column header, no concatenation)

what is my fallacy here?

[Experimenter]

Here is how I would solve this:

You can then cleanup (replace spaces, lowercase, etc.) your new “product types” either after unpivoting, or after the final concatenation.

[bruno29a]

Hi @roberting , not sure what the purpose of the class name string. I mean I get what you’re trying to do, but it feels like you’re trying to define the type, for example if diameter and length are present (but no thread size ) then it’s a tube, and then defining the action based on the type, that is if a tube, then use whatever columns that were used to define the type in the first place.

So, what you are saying is:
if diameter and length are present (but no thread size) → this must be a tube
if tube → string would read “diameter_length”

Then why not simply:
if diameter and length are present (but no thread size) → string would read “diameter_length”

If you do need the product_type for some other reason, then I would still do just 1 condition with 2 results/operations, instead of doing 2 ifs:

if *diameter* and *length* are present (but no *thread size*) then {
  product_type = tube
  string would read “diameter_length”
}

Can you please provide a few sample data, and how the expected results of the sample data should look like?

[Experimenter]

Bruno,
the topic author has some point. The approach you are proposing is shorter - yes, indeed, there can be rule engine used to create rules for each product type explicitly -, however each of those rules most probably must include all the product parameters. So if there are 10 parameters, those conditions will quickly get messy.
If the approach with naming classes by product’s nonempty parametrs works, the fieldnames concatenation idea is quite attractive. When you have concatenated fieldnames “class names”, you can then just use join or dictionary to replace product names to proper ones, and also quickly identify which product types are missing proper name.

[roberting]

Hi @bruno29a ,

well I need to explain: the string basically is another representation of i.e. “tube” .

1. the string would allow for a quick, legible overview of which attributes are used and also could be instantly used for grouping the products in classes.
2. The data will eventually be imported into an Akeneo PIM system, where I beforehand need to define product families and -variant models (defining which attributes to use to form variant axes: i.e. product = screw, variant dimensions according to thread x length).
   to name these models in Akeneo, they each need a code (internally used) that must be unique, but it makes life much easier, if it is also human-readable. Therefore, the string would serve as the internal code for the product model, while “screw” would be the “Label” presented to the user in the frontend.

[Experimenter]

I just wonder what you plan to do if two kinds of product have matching set of parameters. There must be such. I can imagine that, for example, there can be several kinds of products having both length and thread as parameters. Like, screw and threaded pin.

[roberting]

Hi @Experimenter ,
you are right: my example is simplified. I the real table I am facing 5-8 types of just “diameters”, it all adds up to dozens of measuring value columns in total. So my first approach with expressions/rules was not up to the task; I had to endlessly combine MISSING/ NOT MISSING arguments which is not practical.

To answer your last comment: as mentioned above, I have different, very specific measures, like diameters d, d1, d2, D1, D2, which have specific meanings in the industry. If still two different types of product share the same set of features they could still be further differentiated by the product name/description or other parameters, but technically they would share the same product model, which is as far as my task of implementing the solution goes.

[roberting]

Hi @Experimenter

thanks so much, this pivoting approach is something that did not come to my mind at all.

Update: this works perfectly, thanks again!