How machine learning accelerates your Service Mapping implementations

SES1234-K22

K22 K2022

A ServiceNow discovery spoke to setup workflows for your IT operations

CCB1124-K22

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi, everyone. Welcome to this breakout session on the topic ServiceNow, Discovery Spoke. This session is about Discovery Spoke that I've prepared some time back. And with this spoke, it allows you to set up workflows for your IT operations. So my name is Alikutty Abdulrazak, and I work as a senior solution architect at Wipro. My functions include as a TUE lead for Wipro. I handle all the solutions and the prod offerings. Apart from that, I'm also involved in supporting the pre sales and delivery teams. But my experience, I have over 12 years of experience in the IT industry. I've worked in different roles as in service delivery and also in pre sales. On my expertise here, I have [? family ?] worked on different IP workflow products, employee workflow, as well as created workflow products. And I've been also part of community MVP for the past five years, and also part of the developer MVP for past two years from now. So something about by myself. Going to the topic here. So the discovery spoke. So this is a custom spoke which I have built, and this allows you to perform horizontal discovery via flow designer. So being working with different item implementation for a long time, there has been always a need to-- as you know, you have to set up workflows for your IT operations. There are different use cases that you can come across during your implementation. With this spoke, it allows you to set up no code, low code workflow for your IT operation. As a part of this spoke, I have two different actions that have been built. First action is about discovering any device in your infrastructure. It's called as discovered by IP address, and it allows you to discover any of your servers or your network devices within your infrastructure. There is also a second action within the spoke, which is get status details. It is the corresponding spoke related to the discovery, and with this it allows you to extract the discovery result and you can validate whether your discovery is successful or not. A couple of use cases where in real time you could use it. One of the main common use cases that we have is the infrastructure change. So let's say you have to make a change to your server, for example, adding more CPU or adding a disk. Whenever the specific change is implemented by your IT team, you can use this spoke to trigger a discovery to your infrastructure. Since you have the server as your CI on the change, you could access the IP of the CI and trigger this workflow. And with this workflow, what it gives you is the latest changes in your infrastructure. So let's say you have added more disk or more memory. The same things get discovered at the same time, and this allows you to validate that your change has been successful. You can set up such workflows for change. Apart from this, other common use cases that I've come across is when you have alert management. So if you need to remediate the alert by restarting a server, then this is a case where you could use this spoke to rediscover your server and make sure you know your server is back up to normal. That is another use case where you could use it. Another use case is regarding software installation and uninstallation. So whenever you have a software installation happening in one of your servers or any other infrastructure, this spoke would, again, be used to discover whether the software has been installed or not. It would act like a failover, for example, you have a CCM to do this. In case of that installation fail, with the help of this discovery spoke you could actually open a path to the asset team to validate it. So it's kind of an instance failover. Apart from this, you can have it used for any of your orchestration uses with your servers or within your infrastructure, or also on any other discovery request. Now this spoke is available in the share repository. You could search for ServiceNow Discovery and download it. You can also import from GitHub in your source control. Additionally I've also put up a documentation for this in the community blog. So this is the spoke, which is available in share repository here. You can search it for ServiceNow Discovery Spoke and download it from here. The GitHub URL and also the documentation related to the spoke is available within this repository, so you could access all the details regarding it. I'll now show you a couple of demonstration use cases on how you could use the specific spoke for your discovery, for infrastructure discovery. Coming back to my instance here. So I have the spoke already set up in my personal instance here. So you can see that this is the primary action that I have. This is called as a Discovery by IP address. So you can discover any devices from your infrastructure using this. You need to provide the IP address from your CMDB. So primarily, a prerequisite is you already have discovery set up in your instance. So I'll just show you how to test this. When you test it, you need to provide a specific IP address, so I'll be giving a sample IP address here. The second input that you have here is the source. You can specify any task number which is associated with it, which you are trying to relate it to. And also have the option to select an application. So this is a [INAUDIBLE] server that is associated with your discovery. For now, you select this as all and I'll try to test this. Once I click on Run Test, it would actually start triggering discovery on an infrastructure. A discovery status record would be created. If I open the results of this, you can see here that the discovery status has already initiated. The discovery of this device is in progress. Now if I navigate back to my instance here under discovery status, you will be able to see that a discovery is already started here, which is active, which has been initiated by the spoke. And if I go to it, you'll be able to see all the results regarding it. So as soon as this is triggered, system will try to access the device information. Once the discovery is completed you could use my second spoke, which I've built, to access the discovery result. So let's see what the second spoke is about and how you could use it. We're going back to the second spoke here. The second spoke is get status details, where you could provide your discovery status with just an output from your first spoke and then see what are the results. So let me show you how the results would be here. So I would be selecting a discovery status and I would click on Run Test here. I would start extracting the discovery of the results from my status record. And if you see the results here, you can see I will get the complete details of my discovery. This would primarily be an adjacent reformat here. You can see the sys ID of the CI which was discovered, the class of the CI, the IP address related to it. If there was any issue associated with the discovery, that information is also added here and you would also get that issue link, which would be in HTML format. Finally, you would also get the status of the discovery, whether it was successful or not. And depending on these choice values, these options, you could actually trigger your workflows for your IT operations. You can also get multiple discovery value. For example, if you are discovering a subnet of large number of IP, the second spoke would be used to get results of multiple devices as well. So that is about the second spoke. Now coming to the two different use cases that I have set up. So I would be just going through the first flow here, which is a use case for change implementation, and I'll also demonstrate a second use case which is regarding software installation. So this is a flow which gets triggered, the number you change is getting implemented. That's the trigger condition for it. As we do it, what we do here is we would call up the discovery spoke here and the discovery spoke would access the IP address of your CI, which is on the change. You would also see the source as marked as a change request number here. Once this is triggered, you need to wait until the discovery is completed. And once discovery is completed, you can use the second spoke here to get the status details. So depending on the results which we get back-- so let's say I have an issue in discovery the device status was not successful. I can open a task or an incident for it, or if it was successful I can update that the change was successfully implemented. So that is what the specific flow has done here. Depending on what output you get from discovery, the change gets updated. So this is the first sample use case that I've built. I have also another use case, which I will be demonstrating today. So this is regarding software installation. So whenever you install a software, either it might be depending on automation. You have automation enabled using a CIS-EM or any other product, or it may be a manual installation. So right now I've considered a manual installation because I don't have that automation tool. What this workflow does is whenever you have a software request on your server-- so let's say I have considered WinZip as an example here. This is a workflow that would be associated with your software request, basically your service catalog. What we do here is basically it first goes to the manager approval, depending on your process. Once the manager approves, it creates a catalog path for the asset team. Now this can also be an automation. If you are using a CIS-EM, you can use the out of the box CIS-EM spoke for this, which would automate it. Once the task is manually set up by the asset team, in our case here, the spoke would be automatically triggered here. So this would be, again, discovering your infrastructure. It would capture the new software installation information. It will bring it back to the instance here and depending on your software installation status, let's say if the study was a success and I was able to look up the software installation record, it would be a successful installation. If I was not able to discover the software, then the catalog task would be reopened and the asset team would have to handle it. So this is kind of an instance failover where as soon as you close the task, if discovery is not successful, the asset team would have to handle it again, giving a better user experience. So let's try this out. So I have set up a catalog item for this. So I would open my software installation catalog item for WinZip here. You can also request this from Virtual Agent, if you want. That's also possible. I need to select a server here where I would be installing this. So I select my server name here, which I have already access into, so I select the server. So before opening, before going to this, let me just go to the server once and I'll show you what is there currently in the server. Switching back to server here. So this are all the information regarding my Windows server that I have. And if you see correctly, I have around 25 softwares which has been installed in here, and you won't see the WinZip as currently installed as a part of this list. So once I do this workflow, you'll be able to see that the WinZip gets discovered, and automatically it would also help in setting up my IT operation process. So now the request is submitted. I would have initial approval for this, which goes to the manager. It's a normal process of a task setup. Now I have approval here, which I'm just going to bypass this. An approval. So as I approve it, a task would be created for installation. Since our case is a manual installation, task is created. If this was automated installation you could directly install it even without a task. So let's do one thing. Let's also install the software directly on the server. So right now I'm going to switch back to my server here, which I have opened up. I have switched back to my Windows server here where I will be installing the software. So I have the installer here for WinZip. Just take a minute to install it, so I'll begin installing it. So it's a normal process. As an asset team member, once you get the task you try to install it. Generally this would be an automation. You would have an agent set up which would automatically install it. But just for the sake of demo, I'm just installing it. Now if I try to close my task without installing it, it would trigger as a failure. It would reopen my task and it would notify the asset manager. Right now since I am actually installing it, this would actually be a successful use case. And when I close the task, it would trigger the discovery and let me know that the discovery was successful. So that is typically the use case that I have set up here. Now installation is almost getting complete here. OK, so this has been installed and that process is completed, and also we can see the software has got added in my Windows server list here. Now going back to my instance again. Now since the installation is over, I would actually be closing this task manually for now. So as the asset team member I'm just going to close this task. As soon as I close this task, the discovery for that specific device is triggered. So I just open the related flow here. So you can see the corresponding flow and how it is getting executed. So the flow is just opening up. So here you can see that as soon as I close the task here for the catalog task, the custom spoke for discovery is triggered. Now it is just waiting for the discovery to complete, a couple of-- might take a couple of minutes. As soon as it's complete, what it does is if the discovery is a success, then it tries to look up for the software record. Now the advantage here is the catalog of items linked to the software model, and the software model is also a part of your SAM process. In case you are using Software Asset Management [INAUDIBLE],, you can link both the software model and the discovery model together and you can set up your installation process for this. Now let's see if the discovery is getting completed or not. So now it's completed, and the process has also completed. Look up is completed. And if I go back to my device here, software device here, you can see that an additional software is also added. Right now we have 26. And if I scroll down, you can see the WinZip software has got added. It has been discovered as soon as I closed the task, and that has also been validated by my workflow there. So using these two custom actions that we have, you could actually set up any workflows for your IT operations depending on your use cases. It's possible to set it up. And you could use it for any kind of infrastructure validation. With that said, regarding this session, thank you all for watching.