Transcript

X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi, my name is Philip Swann. I am a Managing Consultant at Rangoon. I've been working in ServiceNow since 2014 and in GRC since 2017. I'm also a two time ServiceNow Dev MVP and host of the "Phil Goes Deep" YouTube channel. In this session, I'm going to talk about how to make your code more available. We've all been in the situation where we've written some really nice code and it's really good. We're so proud of it because it works. It works really well even when we test it. And maybe it didn't work to start with, but it does now. And this code we've spent ages writing looks so good. If someone here was to look at this code right now, they would definitely be able to read it. It follows consistent naming conventions, includes meaningful comments with beautiful formatting. It's modular, performant, secure, elegant. But guess what? None of that matters. Gartner published this research back in 2019. And you have seen ServiceNow investing massively in this space. But this is not why citizen development is important. Citizen development is about partnering the people who need the solutions with the people who build the solutions and increasing the speed to value. Citizen development matters because if we do not respond to this demand, the business will be left behind. And business doesn't wait around. Servicenow.com has a page about citizen developers and it discusses these four stages to create an application. Back in 2020, I embarked on an adventure to convert the entire core application of GRC to Flow Designer in 24 hours. Why? To learn. To discover whether it was possible or consider if it even made sense. To be able to answer for myself what is Flow Designer good at? Where does it help? Where are the strengths and where are the weaknesses? As someone who loves to design and build solutions that solve business problems, I am someone who writes code and I want to make that code more available. No matter if I am building an application from scratch or if I have an existing application that I want more people to use more effectively. The problem is when you write code on ServiceNow, it is like gold. And your scripts include, now it is buried somewhere deep in the platform like some kind of hidden treasure that there is no map. There is no X marking the spot. Somewhere there is someone in the business who really needs it but they cannot find it. And even if they could find it, they would not be able to use it very easily, not without writing more code. Even yourself and your fellow developers could be forgiven for forgetting you wrote it. So your beautiful, delicious, elegant code is literally useless. It's useless not because it cannot possibly be used but because it is not practical and thus it is not being used. Or it is being used less than it should be or used less than it could be. So this person out in the business makes a request for a new function which someone else writes or they build. But they don't think about all the things you thought about and they don't build it the way you built it. And maybe it's not so beautiful or it's not quite as performant and it's not quite as secure. Now you have two functions doing the same thing in two different ways. I'm not saying that nobody can write code like you. I'm saying that they should not have to, especially if you already have. Especially if you have spent time solving that problem really, really well. This is the problem. We the developers, the ones who create the workflows and design the applications from the ground up, are not making our code available. Maybe we are not even making it available to our fellow developers and we are not making it available to ourselves, because we wrote a function and forgot about it. So writing code is one thing, but once we start to expose it, we are also documenting it. Flow Designer doesn't just give us the benefits of reducing our reliance on code by providing a lovely UI. It also helps to organize and communicate our application's functions and endpoints. And here is the main point I want to make. It's time to start thinking about our solutions in a new way. Script include is an API. Our public methods are the endpoints. If you build your application with Flow Designer it in mind, your code will become more available by default. But what if you have already built it? You and your customers can still benefit from these simple steps today. First we need to abstract the complexity. Focus on and expose the simplicity. In this example, I will be using the classic class pattern. Special thanks to Travis for his blog on codecreative.io for explaining the various interface design patterns for script includes. Note if you want to make your private functions truly private, you might want to look at the module revealing pattern. So first of all, put all your public methods at the top of your script include. These are the methods which you wish to be consumed from outside the script include. Consider these as our API endpoints. Have them return a call to the private function on a single line. The private methods are denoted with an underscore prefix, and these should only be called from within that script include. Even if the private method is extremely simple, just return the function call with those parameters passed in and this helps to communicate how the API is intended to be used. So we abstract the complexity, focus on and expose the simplicity. For each public message you want to be consumed, now in Flow Designer create an action. Ensure that you are considering the categories and creating them as required according to the design and plan of your application. Here I just use example ABC. Once we have created an action, we can specify the relevant inputs and outputs. Then just put a script step to cool our API and parse the inputs and return the outputs. Now we have created a wrapper for each of our script include endpoints, and we have also been able to enforce the validity of the inputs. And we have organized and published our code. Just take a look at how available our code is now. Once our actions are published, you can see how Flow Designer organizes the application for us. Let's create a subflow. We have the application scope. Here it is CCB1132 named according to this session. Thanks for watching. Next we have the category, example A, And the actions in that category with the info and annotation. When creating the subflow, we can assign that to one of the categories that we created earlier or we can create a new one if necessary. So what I've shown you today is nothing new. Flow Designer has been around for a while. And the concept of citizen development is not new either. What might be new is some of the thinking and the simplicity that allows us as developers to make our code more available, especially for the low and no code community, with just a few simple steps. So we can continue to do that heavy lifting and write the code we love to write while enabling the business to take full advantage and achieve maximum value from the results. In case you missed it, three simple steps. Firstly, organize our script include as an API. Put those public methods at the top so we know how we expect to interact with our API. Then we create actions for each of those methods in Flow Designer using categories to help organize them. And then that functionality is available to be consumed within our applications or by citizen developers. Thank you for watching. Please enjoy the rest of Knowledge '22. And if you want to get in touch, please check out the sndevs.slack.com or #PhilGoesDeep on LinkedIn and YouTube. Thank you. [MUSIC PLAYING]