ServiceNow ini usage of # on SN fields

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

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.

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

ACLI 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