Discovery Pattern - Logs show "setAttribute" but it does not actually set attribute

[Robin J_]

Hello ServiceNow community! I have something which seems like a "bug" to me and could not wrap my head around it. Wanted to share it.

On the table: "cmdb_ci_win_server" I have two custom "String" fields:
Install Date:

Last BootUp Time:

As you can see only one of them is populated. I have created two extra extensions and steps for the default Windows OS - Servers pattern to pull two extra values from "cimv2/win32_operatingsystem". This works as expected for InstallDate but not for LastBootUpTime even if the values are shown in the "Horizontal Discovery Log".

See two screenshots:

The extensions and steps in Pattern Designer is equaly for both of these just that they are catching different values. Why is it that only one of these updates and the other is left blank? I have ensured that pattern is synced to mid server via "Sync Pattern". Also screenshots from my mid server files under: "agent\work\ndl"

For me this seems as a "bug". Can also share more screenshots from Pattern Designer, but here I can not see what is wrong since everything in the logs and checks looks good to me.

Any ideas ServiceNow Community?
PS: This is from my PDI which is on Tokyo, so maybe something there?

Kind regards,
Robin Jacobsen

[Radhika Aluru]

Hi Robin,

can you please try to combine both the extensions and use Transform table or set variables to populate both the the field values from temporary variables?

Regards,

Radhika

[Robin J_]

Hi Radhika!
Good news it helped one part of the problem. 

Results:

The issue seems to be when you are trying to parse two different temporary values. I also tested to combine the "get" steps without any luck. Some testing did result in either one of these showing, not both at the same time. The challenge is that I need to parse two values and it looks like it is then the error happens. 

I tested all 4 steps before doing the final test and each of they work, they do exactly as expected. They list the raw value on "Get" step(s) and they list the parsed value on "Parse" step(s). 

So the issue is boiled down to it being a issue when parsing multiple values. Something there is not looking to work as expected or are looking to be some kind of limitations/bugs as far as I can see. 

If anybody wants to test then this is a good test.
1) Extract minimum 2 values
2) Parse minimum 2 values
3) Insert parsed values into minimum 2 custom fields on a CI

Thanks for the tip Radhika 🙂
- Robin

[Radhika Aluru · Accepted solution]

In the parse variable steps try to use a temporary variable($variable name) rather than using a table variable like $cmdb_ci_win_server[1].u_install_date

[Robin J_]

Wow, there we have it. So the summary for the findings is:
1) If you only are setting 1 variable it is ok to use table variable and also to skip transform table step. This works and is also mentioned in Lab 8.1 in Discovery course. 
2) If you are setting more than 1 variable, then you must use temporary variables + transform table.

Thanks a lot! I really could not wrap my head around this since 1) worked for 1 variable and then I expected that same method to work for multiple variables which it did not. 

Results:

As you can see the "Test" did not show the results as expected, but tried running a new Discovery just to see and this is the result:

So it worked!

And for the parse steps I just saved it as a temporarily variable instead of table variable:

Have a nice day Radhika 🙂
- Robin

[Owais3]

Hello Robin,

Nice one for getting it working!

I'm trying to do something similar, I'm trying to pull the InstallDate like yourself but I'm not using a custom field but using the ootb install_date field that is avaiable on the form.

I've managed to get it working but my install_date field does not populate with the date on the ci.

My WMI Query is set like this:

And for the Parse Variable the settings are set to this:

This is the output:

I read above in your post that if we are pulling a single value then we don't need the transform table so i've got rid of that.

Any idea what I maybe doing wrong?

Or is it the field install_date on the form which does not accept the date format i.e 20190410?which is being pulled because the ci install_date format is in DD/MM/YYY HH:MM

Any solution?

Thank you