The ServiceNow Discovery spoke allows you to configure horizontal discovery in a flow designer thereby providing the ability to drive several kind of business logics via the no code approach. You could use it for use cases like triggering a discovery when a change is implemented or when an alert is remediated or when a software installation or uninstallation task is completed or during an orchestration activity involved within your infrastructure. You could either retrieve the update set after downloading it from Share or directly import it from the source control after forking the repository at Github. The spoke contains two different actions.
- Discover by IP Address – This allows you trigger a horizontal discovery using an IP Address. It requires an IPV4 address and 2 optional parameters.
- IP Address – The IPV4 address of your infrastructure device or the CI
- Source – The source of discovery eg Change request number, Integration ID etc. The value provided is updated on the Source column of discovery status record. The default value is DiscoveryAPI
- Application – This displays the list of all mid server applications in your instance and determines the mid server selection criteria for your discovery. The default value is Discovery but you could change it according to your setup
Note: You cannot direct the discovery to any specific mid server but it will choose based on the application that is allowed on a mid server.
The output of action is the related discovery status record.
- Get Status Details – This allows you to validate results of any discovery status record in your instance and not just the one returned by the former action. It requires the discovery status record as the input.
The output of this action is an Array object of all devices discovered and contains the discovery results in a usable format. It will also return the total count of all devices that were discovered.
The Device object contains
- Operational Status – A choice value and contains three options
- Processing – Discovery is still being executed
- Successful – CI is either created or updated or there are no issues reported
- Not Successful – CI is not discovered or having issues in discovery
- Device Id – The Sys Id of the device that was discovered
- The Source Address – The IP Address or the Source name of the CI
- Issue Count – Number of issues derived from the discovery log. This value is generated from the device history(discovery_device_history) record and is mapped to the Issues column
- Issue Link – An HTML link that could be used in Journal field like work notes. The link will direct you to the list of all warnings and error logs associated with your source address. Use this for cases where Operational Status is Not Successful
- Device Class – The CI Class of the device discovered eg Windows Server, Linux Server
- Last Status – The last status column value of the device history eg Created CI, Updated CI, Alive not active not classified, Active couldn’t classify
Sample output – Contains one or more devices
Note: There is a sample flow shared in the update which demonstrates how each of these outputs could be used in a flow.
We have also noted that within flow we attempt to pull back the Device Object Array but cannot place these pills into updating fields in the record. They are grayed out.
Also noted that some discoveries of CI's will take some time to complete for this give us accurate results.
So are we missing a step here or something else?
