Rich Martin • 00:02

Hello, everyone. This demonstration will focus on showcasing how Itential enables fulfillment of multi-domain and multi-technology product designed by customers within ServiceNow OMT. As part of the demonstration, we’re going to cover a few pieces, first one being being able to create automations within the Itential Automation Platform and simply in an easier fashion publish that as an RFS within ServiceNow OMT. Once the RFS are actually available, we’re going to showcase how it’s easy to create a product within the ServiceNow SOM catalog, taking advantage of the published RFS. And the final part of the demonstration is going to focus on how do we kick one of these product orders off, taking advantage of an emulated portal or an API, and see how it actually gets decomposed and fulfilled by Itential. Let’s get started with the demonstration. Currently, we have navigated to Itential’s Automation Studio, where in front of you, you actually see an automation canvas where the SMEs across three distinct domains have created automations to help fulfill the product that was created within ServiceNow.

Rich Martin • 01:14

As you saw within the slides, the managed application hosting product actually breaks down into three different domain-focused services. First one being infrastructure. This particular automation actually goes and interacts with AWS, leveraging AWS native APIs in order to create infrastructure for the application to be installed. The second automation created within the Itential Automation Platform by the network SMEs focuses on providing access connectivity in an automated fashion. You’ll notice as part of this automation, we’re integrating with several different systems as sources of records in order to federate data to make sure that we can provision the right configuration on devices as well as SD-WAN networks. The final bit of the service actually requires us to create security rules. So end-to-end, the client or the application can actually get access to data, which might be sitting on-prem on a particular server or in another cloud.

Rich Martin • 02:17

So now that we have actually built these automations within Itential, the next point would be to actually publish those as RFSs. In our previous demonstration, we had showcased how Itential actually makes it very easy to publish these automations as RFSs. As you can see, this is an internal self-service automation available for any SME who had created that workflow to be able to publish that as an RFS within ServiceNow OMT. In this case, if we ran this automation, it’s going to take advantage of the end-to-end app connectivity service, which is a workflow that you saw early on, that will be published with all its required parameters within the OMT resource and service specification. So now what I’m going to do is, instead of actually kicking this off, because we have already published three of those automations as RFSs within ServiceNow OMT, what I’m going to do is I’m going to traverse and navigate to the ServiceNow OMT app. As you can see, now I’m within the ServiceNow OMT app. What I’ve currently pulled up are all the service specifications.

Rich Martin • 03:29

These are the three different RFSs that we have published, number one being CloudFocus, the AWS cloud infrastructure. You’ll notice, in order for us to actually invoke and make sure the fulfillment goes through, these are the automatically generated RFSs. specification characteristics. So as part of the publish capability that Itential provides, we were able to automatically generate these and no one had to manually do that within the ServiceNow ecosystem. And we did this same exercise with the other two RFSs as well. The other two being the access connectivity, which enables us to provision network devices and SD-WAN controller policies. And the last one being the Itential security rules, where we interact with Panorama and have to pass on, you know, some of these parameters are default, some of these we actually federate real-time from different systems, and some of these are actually provided when the product is requested. So now that we have all three RFSs actually published, what I’m going to do is navigate into the product. So, you’ll notice this is actually the product that we created taking advantage of the RFSs that were available. And when I go into the catalog hierarchy, you can see how it actually decomposes down into three different RFSs published by Itential. The first one being the cloud infrastructure, which is needed for us to deploy the app, and it has its own set of parameters required for this automation to run. The second one is access connectivity.

Rich Martin • 05:03

And the third one is security rule creation via panorama in the security domain. What’s interesting here is because even though each one of these automations or RFSs that were published have their own set of requirements with respect to inputs, what we have done is in order to make life easier for the product requester, which are the consumers, we have specified only nine characteristics at the product level. So, you’ll notice here, as long as when someone is requesting the product, can provide these nine pieces of information, we will be able to decompose the product at the ServiceNow OMT level. And once it’s decomposed and requested for fulfillment, ITENTIAL will get those inputs and actually make changes into the network controllers and clouds and network devices accordingly. So, at this point, what we have established is we have published the RFSs within ServiceNow OMT. We have actually created a version product leveraging all three RFSs that were published, and now we’re ready to actually order one of these products and see how the fulfillment goes through. So, in order to emulate an external portal, as well as, you know, potentially an API, what we have done is we’re actually going to take advantage of ITENTIAL’s ServiceNow application.

Rich Martin • 06:23

So, this is another application that ITENTIAL has published within the ServiceNow store, which enables the end users to point towards any ITENTIAL automation platform and dynamically render all the available automated services. So, in this case, what we’re going to do is we have actually exposed the managed application hosting service, as you can see here. And when I click on it, it automatically renders a form that would actually created within Itential. So at this point in time, what we’re gonna do is we’re actually gonna fill out the name and we’re gonna fill out all the fields that are required for this product to be requested. B2, call it org1234. Org24, potential, CIDR block, we’re gonna ask for 14, 024, just a small one. And I want the gold and I’m gonna ask for the deployment region to be in North America because that’s where I’m launching my application.

Rich Martin • 07:31

My deployment type is gonna be production and I’m gonna go ahead and provide some of the source and the destination address because I already have that available, right? So I’m gonna say 14, three and then for the destination, let’s go and call it, All right, so now that we have successfully filled out all this information, what we’re essentially doing is when this automation is requested, Itential now calls ServiceNow back using the product API that was actually published using the ServiceNow OMT application within ServiceNow, right? Anyone can call it, whether it’s Itential itself, whether it’s another portal that we’re emulating here, or it could be another pipeline that is requesting this product. In this case, what I’m going to do is I’m going to go in and kick this automation off. As you can see in the background, it is now calling the product API being published by ServiceNow, and as a result, what we’ll go and see is within Itential, we actually have a log of if any of the products were kicked off. You’ll notice at this point in time, there is no request coming down from ServiceNow OMT to Itential yet, because we still have to go back.

Rich Martin • 08:54

to service now within the OMT app. Take a look at the listed orders and we’ll refresh this page. You’ll notice there was a new order that was generated just now, right? So when I click on this, we’re gonna go and approve this. So this is the normal change management process that someone goes through in order to actually request and approve the product that are incoming from the customer. So at this point, once I approve the request, it’s gonna go into in progress stage. And once it’s in progress,

Rich Martin • 09:29

What we will do is take a look at all the parameters. As you notice, it has successfully gone into in-progress state. I’m going to go into the order line items, and let’s go take a look at the order characteristics. As you notice, the end user only had to fill out nine pieces of information. However, as part of the decomposition and federation of data to support fulfillment, we had to go and fetch all the other pieces of information, whether it’s from different systems or are set as default. These are a total of 32 different parameters that we have to potentially send down to ITENTIAL in order for us to actually make changes into the infrastructure. At this point, I’m going to navigate to the order task.

Rich Martin • 10:18

As you can see, there are certain rules that you can put at the product level to make sure that all of these get kicked off if the order was actually approved. But in this case, because we have change management in place and we want to actually kick off these orders one by one, what I’m going to do is I’m going to kick the access connectivity bit off. Let’s go ahead and click on one of these. What we’re going to do is we’re going to validate the incoming characteristics, which is correct here. At this point, I’m going to go back to details. Let’s mark this as a qualified product. Save it, and as soon as I click onto the Create Outbound Fulfillment Request, what it does is it internally actually runs a ServiceNow flow that was created by Flow Designer.

Rich Martin • 11:04

But within the Flow Designer, I’m going to bring it up real quick, within the Flow Designer, we’re actually taking advantage of some of the custom actions that Itential has exposed within the ServiceNow ecosystem. So you’ll notice there are certain tasks in here that are not just native to ServiceNow, they were actually exposed by Itential. So anyone who is actually building out some of these subflows can also take advantage of that independent of the Snow OMT app. So, what I’m going to do now at this point is now that we have verified the order characteristics and put the state as qualified, I’m going to go ahead and create an outbound fulfillment request. So, at this point, you know, the OMT app is actually making an API call towards Itential using the TMF-641 in this case. So, as you notice, we have acknowledged that the order has been requested and Itential has accepted it. Now, if we go into this particular portal and I’m going to refresh it, you’ll notice all the way at the bottom, currently shows that the current service is in qualified state.

Rich Martin • 12:10

So, until the automation is actually correctly fulfilled within Itential, this will not go into close complete. So, in order for us to check what’s actually happening within Itential, what we’re going to do is we’re actually going to come in here within the operations manager. This kind of gives you a view of all the jobs that were actually started from a fulfillment perspective. Right? So, as you notice, we have successfully fulfilled this. Now, if I go back into the service order, you’ll notice this service order has been successfully completed because Itential already ran the workflow within its own system and actually made changes into a network. At the same time, what we can do is go into the parameters.

Rich Martin • 12:56

for their product inventory. If I go into more, go to product characteristic. At the end of ITENTIAL actually running its own automation, we actually came back and updated ServiceNow OMT’s product inventory with which IP address we actually got back from Infoblox and which interface that we actually chose to provision the network assets in order to support that product. So because we have this two-way communication, anytime ITENTIAL actually performs actions against the infrastructure, the network, or the security, we’re able to capture relevant details and update it back so it ties everything back to the product order and the order line items. So this was an example of how, you know, someone can create automations within Itential, expose those as RFSs, and then within the OMT app, create products, leveraging those RFSs, and then, you know, the consumers can come in and request those. And this was just part of an example of how things actually get fulfilled. So if I come back here, you will notice one leg of this particular product is completed, right?

Rich Martin • 14:06

Now, for the next piece, if we wanna go and choose a security rule creation, we can also kick that bit off by going in here, reviewing the characteristics, going back to the details, putting this in qualified mode. saving this, and then creating an outbound fulfilling request. Then the same process occurs. So until all three of these services, three of these RFSs are actually close complete, this product is going to remain in draft state and ultimately, once all of them are close complete, now the product can be closed and the customers can be notified. So that was the end of our demonstration where we showcased how Itential is able to take advantage of its integration and automation capability to support rapid fulfillment of products being created within the Itential ServiceNow OMT application.