Forum Discussion

pperreault's avatar
pperreault
3 years ago
Solved

inventory reporting with property data

What are you all doing to get clean inventory reports with consistent property value data? When creating inventory reports it can be a challenge to populate them with the desired property data due to the varying names, e.g. auto.productserial, auto.endpoint.serial_number, the data may be found under. The solution to add them all and edit the csv afterwards is clunky.

  • Anonymous's avatar
    Anonymous
    3 years ago

    Makes sense, would be a matter of your logic defining inheritance priority. So if both auto.productserial and auto.serial_number both exist, which one should be unified.serial_number? 

    Obviously the first step would be to check the existence of any of the properties that would feed in. If only one exists, that becomes the unified value.

    If more than one exists, check that the values are not null (you can have a property that exists without a value). If only one has a value, that one becomes the unified value.

    Of the ones that exists, that have non-zero length values, you'd have to decide which one would take priority. This could be simple or complex, depending on how fancy you want to get. 

    Something simple might look like this: 

    // load in the properties that you want to feed into the unified property.
// put them in order of priority. The later items in the list have priority
// over earlier items in the list.
properties_to_consider = [
  "doesnt_exist_property",
  "auto.serial_number",
  "auto.productserial",
  "auto.some_other_serial"
]

values = [:]
unifiedvalue = "serial"

// Lookup the property values, store any that exist as a result.
properties_to_consider.each{
  propValue = hostProps.get(it) ?: ""
  if (propValue.size() > 0){  // this ignores any non-existent or null properties
    values[it] = hostProps.get(it)
  }
}

values.each{k,v->
  println("unified." + unifiedvalue + "=" + v)
  println("unified." + unifiedvalue + "_from=" + k)
}

return 0

     

    You don't necessarily need to do the second println statement, but i find it handy in this kind of situation to record a property telling you which property won the priority contest. You may notice that this actually prints out all of them. That's true. But LM only pays attention to the last value of any duplicate property lines. In my case, with fake values for serial_number and productserial (and the other two are null in my case), the output looks like this: 

    unified.serial=123456789
unified.serial_from=auto.serial_number
unified.serial=ABCDEFGHI
unified.serial_from=auto.productserial

    If you test this from the PS screen, you'll see that the last two lines overwrite the first two. That's why the order of the very first list is important. The last, existent, not null property value will be the one that goes into the unified property.

4 Replies

Sort By
  • Anonymous's avatar
    Anonymous
    3 years ago

    Gut reaction is why not make a property source that consolidates those properties into a unified set of properties (unified.serial_number, for example). Haven't really thought it through, just an idea.

  • pperreault's avatar
    pperreault
    3 years ago

    I thought of that possibility, haven't chased it down yet. What I don' t want is a list of the values from all the possible properties, which unless there is logic to remove repeat values, this might result in.

  • Anonymous's avatar
    Anonymous
    3 years ago

    Makes sense, would be a matter of your logic defining inheritance priority. So if both auto.productserial and auto.serial_number both exist, which one should be unified.serial_number? 

    Obviously the first step would be to check the existence of any of the properties that would feed in. If only one exists, that becomes the unified value.

    If more than one exists, check that the values are not null (you can have a property that exists without a value). If only one has a value, that one becomes the unified value.

    Of the ones that exists, that have non-zero length values, you'd have to decide which one would take priority. This could be simple or complex, depending on how fancy you want to get. 

    Something simple might look like this: 

    // load in the properties that you want to feed into the unified property.
// put them in order of priority. The later items in the list have priority
// over earlier items in the list.
properties_to_consider = [
  "doesnt_exist_property",
  "auto.serial_number",
  "auto.productserial",
  "auto.some_other_serial"
]

values = [:]
unifiedvalue = "serial"

// Lookup the property values, store any that exist as a result.
properties_to_consider.each{
  propValue = hostProps.get(it) ?: ""
  if (propValue.size() > 0){  // this ignores any non-existent or null properties
    values[it] = hostProps.get(it)
  }
}

values.each{k,v->
  println("unified." + unifiedvalue + "=" + v)
  println("unified." + unifiedvalue + "_from=" + k)
}

return 0

     

    You don't necessarily need to do the second println statement, but i find it handy in this kind of situation to record a property telling you which property won the priority contest. You may notice that this actually prints out all of them. That's true. But LM only pays attention to the last value of any duplicate property lines. In my case, with fake values for serial_number and productserial (and the other two are null in my case), the output looks like this: 

    unified.serial=123456789
unified.serial_from=auto.serial_number
unified.serial=ABCDEFGHI
unified.serial_from=auto.productserial

    If you test this from the PS screen, you'll see that the last two lines overwrite the first two. That's why the order of the very first list is important. The last, existent, not null property value will be the one that goes into the unified property.