Multi-source eBonding– the one ring to rule them all

CCB1125-K22

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi. I'm Christopher Carver. And I'm here to talk to you about multi-source eBonding. Before we get into that, let's talk a little bit about me. I'm a technical architect here at Textron helping them realize ServiceNow across the enterprise. Textron has customers in defense, aerospace, specialized vehicles, turf control, and fuel systems. Now, let's go ahead and get into this topic of multi-source eBonding. So Textron actually has engagements with a lot of external IP service suppliers that perform various operations within our enterprise. They can do everything from server support to database support and call center and data recovery. Now, Textron needs to eBond with each one of these individual companies and making sure that our ticket communicates with their ticket in their ticketing system. So initially, when we set out, it was a one-to-one correspondence between our tickets. However, have you ever run into an issue where you need to coordinate the work with multiple external service suppliers where you have an outage that involves multiple parties to communicate? Well, initially, our major incident manager, here at Textron, would end up creating four or five incident tickets and make them children under a big ticket, but then they would have to manually ensure that the coordination of information from one supplier made it into the other supplier's ticketing system. This is a huge burden for them and didn't scale very well. So we needed to create a new solution to allow us to work together. And the idea behind it is that we only wanted one ticket here at Textron, and updating that one ticket at Textron actually updated all of our IT service suppliers across the board. What this meant was is that if a supplier updates their ticket, that information would flow to ours. But then our system on the ServiceNow platform would be intelligent enough to update the other suppliers and their ticketing system. That way the data flowed smoothly between suppliers. And that no supplier actually needed to know who the other company was that they needed to interact with. We took care of all of that in this new framework. So let's talk a little bit about the ServiceNow components that comprise of this multi-source framework that we're putting together. So the first thing is we take advantage of the out-of-the-box experience on the platform for imports [INAUDIBLE].. OK. That is a very powerful ability within ServiceNow. But we went ahead and just leveraged out of the box that other suppliers will actually write into the single import table, and then we take care of that transformation. The other thing that we needed to build, and this is the core, this is the part that really makes this all run, is we did create a custom table called the relationship table. And this is a one to many relationship where we have our one ticket but then we know which tickets on the supplier side to update and keep them updated. And lastly, we did create another custom table. And it's our payload table. That's to ensure that as we're sending outbound messages, that we keep track of those messages and then are able to recover and do some data recovery if necessary. And we'll talk about that in a little bit. All right. So let's now move on to the inbound topology. So everything that you see in blue is within the framework. It's static OK. That way as we on board new suppliers during the initial engagement, we would just work through the data mapping session. How do you talk to us? Because as soon as you send us the right message and we then set them up, everything is set in place. So I don't have to rewrite everything from scratch for every supplier. So what they'll do is they'll actually write into the import set staging table. Then we'll perform the transform. I say we, but we know it's ServiceNow at the back end, the platforms do the transform. So we set up that transform to actually do the logic. We do trust our vendors, but we also want to verify all that data coming in before we write it to our system of record table for that incident or ticket. The target table for our transform though is our relationship table, and that is key. Once we've written to the relationship table, we then know on the final steps of the transform, do we create a new ticket? Or do we update a new ticket? Now, the outbound topology is a little bit free. There's a little bit more involved. However, we try to streamline out all of the static areas, once again, in blue. That once it's set up, you don't have to change it for every supplier. The other items that are colored is what we would have to put into place for every supplier as we on board them. So we did set up a standard business rule that would look at the ticket table of the ticket that we're looking for, and then we created an event that's unique for every supplier. And the reason for that is just as we said in the inbound, where the supplier needs to talk to us how we ask them to talk to them, in return, we talked to the supplier how they want us to talk to them. So we actually had to create an event that would be sent, and then we would take that event and process that and build up the payload of the data that we've captured from the ticket. We then send the payload down to our REST handler that would end up sending that message over to the supplier. And we use asynchronous communication calls, and we'll talk about that in a little bit. And then when the supplier is done, they'll send that message back. And then we actually have another handler that's listening on the ECC queue on processing that message back. Because typically, when a supplier responds back to you, they have their own structure of their response message. So we have it unique for every supplier. As that gets sent back, that also is updating the REST payload table. Now, on the far back inside is the payload monitor. And the payload monitor, what it does, is schedule a task that is set up in ServiceNow and it, monitors the REST payload table. And what it does is it determinants do I try to resend the message? Has the message timed out? Because we have to remember the internet is like the wild, wild west. You don't know what's going to happen. Something can happen in between the external service suppliers ticketing system could be in the process of being upgraded. So we need to be able to true up all of the missing messages that we weren't able to send to that supplier at a later date. So let's talk about some of the lessons learned that came about all of this. So the first thing is the concept of reflect or deflect updates coming in from the external service suppliers. So imagine you have this large party. Everyone is talking together. One of your service providers, they're done with their ticket. So if they close their ticket, do you reflect that closing your ticket. Well, if you do, your other service suppliers might think you're closing it out. It's all solved. So the question then becomes should I reflect that change or deflect it? And in that case, we would have deflected that change, just made a work note and pass that work note on to the other suppliers letting them know another supplier has closed out the ticket, is they're done. That might trigger them to take further action on their part. The next part is asynchronous REST calls. This was a game changer for us. It not only helped us improve our performance, but it also helped improve our scalability and led into the third point. Now, I included a link in this presentation. I don't know about asynchronous REST calls. I totally recommend you read up on that. And the third point of scheduling automatic recovery, that was because of an outcropping from asynchronous operations. We were then able to perform that automatic recovery, and that was a great lesson learned. Because we used to do synchronous calls, and that was a real performance killer and made automatic data recovery very difficult. The next one is truing-up those conversations. Back to that party. You've got a big party, but now you need to eBond with another supplier. You're pulling in this new supplier who needs to do some work, yet they're late to the party. So you need to be able to true up all those prior existing conversations and files that you've been sharing, and let them in on what that conversation is about. So don't forget about turning up those vendors keeping them up to date. And lastly, don't forget about deBond. It's just as important as eBonding. Sometimes you need to decouple your ticket from another vendor. So make sure that you work through that with your vendor, and how you can accomplish that. And finally, if you're interested in pursuing multi-source eBonding or want to see you how we've done it, we do provide a copy of this framework on GitHub. So if you're interested in reviewing, testing, deploying, or even contributing, I'd love to hear from you in the future. Thank you. [MUSIC PLAYING]