ServiceNow ini usage of # on SN fields

Started by Manj75, September 30, 2019, 13:34:36 PM

Previous topic - Next topic

Manj75

Hi Herve,

Another quick question or confirmation.

In the sample ini file there is a usage of the '#' on a ServiceNow field, as it appears this is a dereference to a record member - is this correct?

archi.elements.*.property.company                                     = company#name
archi.elements.cmdb_ci_aix_server.property.processor          = processor#display_name
archi.elements.cmdb_ci_aix_server.property.pvus_per_core   = processor#processor_mapping#pvus_per_core

If the member if not found then the element name is stamped in the property - is this expected behaviour.

Lastly, on a separate note and not sure if it is currently possible or can be a future enhancement on your roadmap - it would be really useful if the mappings can be conditionally be determined based on a SN field obtained, e.g. IF SN field 'is_virtual' = true THEN map archi_class="Node" ELSE archi_class="Device".  This type of feature can be very useful.

Thanks,
Manjit

Hervé

Hi Manjit,

The "#" symbol indicates to the plugin to get a sub-property.

For instance "company#name" means to get the "name" field of the "company" object. This company object could be directly provided in the JSON returned by ServiceNow or provided as a link. In this case, my plugin calls the URL to gather the object.

The following error cases are managed:
     - if the object "company" does not exist, then the plugin prints an error in the log file
     - if the "company" field is not an object, then the plugin prints an error in the log file
     - if the "name" field does not exist, then I do not remember what happens, sorry  :-[

Regarding the conditional mapping, you can already do it as the plugin allows you to parse several times the same ServiceNow table with different parameters.

So you could parse a first time with an "is virtual" filter and map to Node, and a second time with an "is not virtual" filter and map to Device.

Best regards
Hervé

Manj75

Regarding your response to my second point:

QuoteRegarding the conditional mapping, you can already do it as the plugin allows you to parse several times the same ServiceNow table with different parameters.

So you could parse a first time with an "is virtual" filter and map to Node, and a second time with an "is not virtual" filter and map to Device.

This, as you say I would have to run 2 consecutive import runs for each value of is_virtual mapped to the different Archi class.  This will be the same as my issue with large data sets that I want to run in batches and cannot automate in a single script or using ACLI.  When you look at supporting that can you take the route of the suggested alternative option stated in post
QuoteACLI to import from ServiceNow
, which will iteratively repeat the import where the CMBD table of relationship is repeated instead of just running the last defined instance.

e.g. If I specify in the ini then the same cmdb_ci_linux_server is imported twice even if there is no filter it will just repeat, but in case of different filters then it will be two different sets.

## Linux Servers - map physical
archi.elements.cmdb_ci_linux_server.snow_table                          = cmdb_ci_linux_server
archi.elements.cmdb_ci_linux_server.archi_class                            = "Device"
archi.elements.cmdb_ci_linux_server.folder                                 = "Enterprise ServiceNow ITSM"/"Servers"/"Linux"/os
archi.elements.cmdb_ci_linux_server.filter                                    = &sysparm_query=is_virtual=false

## Linux Server - map virtual
archi.elements.cmdb_ci_linux_server.snow_table                            = cmdb_ci_linux_server
archi.elements.cmdb_ci_linux_server.archi_class                            = "Node"
archi.elements.cmdb_ci_linux_server.folder                                 = "Enterprise ServiceNow ITSM"/"Servers"/"Linux"/os
archi.elements.cmdb_ci_linux_server.filter                                   = &sysparm_query=is_virtual=true

This would be the same suggestion I put on thread 'ServiceNow plugin of large number of relationships' if you can provide this solution separately to supporting ACLI it would be fantastic - many thanks.

Btw - when I tried this I encountered a bug on filter for CI's and will raise it on GitHub, basicaly it adds it as a separate sysparm_query in addition to operational_status=1.

Thanks,
Manjit