[Music] hello and welcome to creator toolbox this is the show brought to you by the servicenow developer program where we try to give you the servicenow developer the tools you need to be successful building things on the now platform before we get into today today's show we're going to do some introductions so we'll start with earl hi everyone i am earl gk i am a developer advocate here at servicenow i am about i'm close to five years on the platform uh just joined servicenow about six months ago uh uh but before that i was with a bunch of the different universities in california so mostly higher ed nonprofit mark hey everybody my name is mark scott i'm a solution architect at servicenow and uh prior to this i was doing consulting with a bunch of different companies uh doing implementations which was a lot of fun uh i've been on the platform for about i think it's five years about same as earl uh helsinki i think it was was my real first release that i got into so no i think that's no i was geneva i think so okay somewhere in there yeah in that geneva helsinki area that's that's where i came about nice and my name is brad tilton i'm a senior developer advocate with the developer program here at servicenow i've been building on the platform for a while as a customer partner and employee and i'm excited to get into it this is i think we're in week four of our san diego release season this week's all about integration hub and uh with that earl is going to show us one of the new features that we have an integration hub and the san diego release before we get into that there's a little uh data pill san diego thing uh to earl's left and all of our san diego videos i have that on them so you can easily identify that this is a release video sweet okay so jumping into it uh today we're going to be talking about a specific thing that they added into integration hub to solve a uh problem that would happen with um a very specific problem where uh i mean i feel like this happened to all of us like i remember this happening when when i was work when i was on platform with uh workflows it's like whenever any integration that you potentially have you would be um you build the integration you build the whole thing and it's working perfectly fine something like someone signs up for access with another system and then a workflow fired off in integration to requisition the access via a rest api or something like that and then um one day you wake up and you have 100 tickets sitting in the incident queue because um they their api went down or they they had made it into api and they didn't tell anybody um they had maidens on their api and they didn't inform you uh which is why changing change is important but um so now you're sitting there thinking like oh how do i reset workflow contacts how do i um make sure this happens that but it went down the wrong road workflow branch now because it failed um we never accounted for this uh so the thing that we're talking about today is a new form of retry policy strategy called retry after um it's something that has been around for a while but now it's supported inside integration hub within flow designer we're going to be seeing looking through a lot of what that looks like uh pretty quickly and um the new system property that comes with it and the updates to the operation views that uh came along with it in san diego but that's one of the primary use cases it's like oh the api is down for maintenance and they know when it's going to be up again um or uh you another more common one is an api has throttling because you designed a workflow to call an api of 3 000 times in one second it's going to it's going to throttle you um or you launched a program and everybody went straight to the sign up button and now um like you weren't thinking a hundred people were going to sign up at the same time but when you just launched a service a hundred people did sign up at the same time therefore you got throttled um so the retry after policy uh is what solves for those like two primary use cases throttling and when you know an api is going to be down so let's jump into it i'm going to share my screen now uh there's us hi we're still here um fun fact fun behind the scenes fact um i tend to do all the scene transitions but also i'm not when someone i'm also doing the driving i get like confused sometimes so if if screens shuffle around wildly and if we're on the side versus on the bottom that's probably my fault but anyways i'm gonna just show the screen now okay so um i'm in a brand new san diego instance i just uh um requested this yesterday i believe because i accidentally let my pdi uh uh go away so here's a freshman okay you had all you had everything backed up to get and so you were you were good right i actually did yes i have that's it's also why i'm like i i really don't worry about my pdi expiring is because i just back everything up um it's like second nature to me to make sure something's attached to a git repository or um if it's like i have somebody else's update set i'm always making sure to re-export it just in case so here's the new san diego instance look at ooh ah next experience um so reach my policies you can find them in and credentials of integration hub and you'll see that there's three default uh retry policies here and so one for uh resc and soap soap calls one for jdpc and one for sftp um to utilize this new retry strategy you're going to want to create a new one and uh we'll call this the retry after um we'll see and it only works on rest and soap calls so you i have http as the connection type here and you'll see that the honor reach i after header uh appears here and if i change it to jdbc you'll see that it's not option it's not an option there so under http http uh honor retry after header uh there's a couple of things i want to configure so um in case you don't know how some here comes our faces because i'm going to be talking for a bit here comes our faces i try to give you a warning brad i try to give you a warning i know i was like i was taking the time um so uh if you don't know how um rest a lot of rest apis work is when you send a request to an api via rest um it always comes back with a status code and there's many status codes i'm not going to talk about them right now um uh each one or anything but the main one that we're thinking about right now is the status code four to nine so let's if this we're going to say if the k if the status code comes back with a 429 429 is the one that is associated with retry after and so if you if we ever see a h http call in flow designer um that says the status quo is four two nine we automatically know hey oh okay this we're probably going to retry something here and we're going to try to honor the retry after header here um because often a good api if they have a 429 status code they should also have the retry after header and um i think i said this on one of last week's episodes uh what an api is only as good as the documentation that they provide for it and so a good good well documented api will know will tell you like if we if you get a 429 you should expect this header and once and then you have to figure out what you want to do with it and so we're going to say here if we ever see a 429 we're going to try to get a retry after header and um we're going to say uh the max amount of time is uh 30 seconds for it to try to do the retry and if it's if it's anything longer than that then we'll do we'll just in our use case we'd probably like fail it fail the um that part of the section and then like do something to account for it like in a try catch or a new try catch watch last week's episodes haha um but okay so we haven't we we've created a new retry policy so i'm going to go ahead and submit that and now i'm going to jump into flow so earl before you do that i just want to point this out that retry policy that you had there where you were setting that up that's where we normally would put retry policies this is new on top of that right so this is the same place that you would normally put your regular retry policies there's just some extra in here so don't go looking for a different place yeah um that's why i want like the the episode i think we just titled as retry policies this is specifically a new retry policy strategy within retry policies so retry after is just a new strategy within retry policies so this is there's a bunch of different retry policies that you can have in san diego it's specifically retry after that is new right all right so going back into flow designer i'm gonna go ahead and create a new action and i wonder if we'll be able to do any of this through flow designer in the future maybe we can ask somebody on the integration hub team on friday wait what through floater center yeah well if we'll be able to do that from within flow designer like the ring credentials you know that sort of thing that would be convenient so i'm going to add a step here called rest uh if you don't see this within your in uh within your flow designer when you create an action it's because you have um haven't turned on the plug-in for basic integration hub um rest steps are included in the very very bottom the lowest package of integrator the starter yeah that's what it's called thank you uh so i'm creating a rest step um i have a api that i've already set up um let me go define inline uh at um dot uh servicenow.com um it's an api that i created specifically for this demo um what it is is uh whenever you try to call it with a get message it essentially returns a 429 error and that's all it can do it doesn't know how to do anything else um so for this demo purposes we're using that so that for the sake of seeing how it works here um sorry did you say something no just that api has one singular function it does one thing it's a great thing though it's a demo all right so um uh we're gonna we're gonna call that manually and we're going to say oh i'm going to not turn on retract policy so down here is where you would enable retry policy so i'm going to go ahead and just test it out how it is and let's go look at what the um the result says oh here's the demo part waiting for things to spin oh so one of the things i wanted to point out uh every time you use a connection inline in flow designer i always feel super dirty i'm like i i know i should oh yeah 100 yeah it's never a good idea to define your connections inline but you know you should always define to find it outside of that but whenever i do it in line i'm like well we'll just do it real fast here it'll be real fast and and i'll come back and clean it up later never yeah so what is the best practice mark best practice is to to define the connection within a rest message right and then be able to pull that down in your um uh your drop down from the top of your designer flow instead of building out each one of those urls individually it should come from a predefined url that you've already uh built out uh i also like the fact that your production you've put me full screen almost it's like tell us exactly how to do this while your test is running in the background and i'm i'm i'm i hope i'm saying it correctly because that's that's a lot of pressure that's that's what i would do it also just makes it easier um like no one wants to have to update an entire action when api changes yeah uh oh when do we hit the refresh button i'd say did i have to should i have to press save first i'm just gonna say first it's always a good idea yeah so creator toolbox demoing waiting this didn't happen last night when i practiced this this is like let's go to happy hour level here this is we can't even say we'll edit this part out in post because this just gets posted published live right away i mean we could say that if you want all right refreshing yep refresh yeah sean hi kevin no pressure now your thread's hung thank you supportive y'all yeah this is gonna be one of those situations where right when we try to do this like pdi is one intermediate maintenance or something it'd be awesome use the s to switch nodes i don't have that installed can you scan the transaction yeah that's probably a good idea first i mean try it it's worth a try right well it's not even showing me this page where it shows the transaction cancellation hmm there you go well you're you're the eye's not sleeping so that's a good a good thing hey there we go did it save [Music] nope you asked too much did it so what were we doing you were testing it what it looks like without the did you just test like an empty flow is that what we were testing no we're testing the action or an empty action yeah that might have been one no because it actually was running yeah here it is see look oh did i not no yeah there you go i think because you hadn't saved after testing yes so now it's like running lickety-split boom we learned it here so you everybody save that's the save early and often yeah did i mess up the url yeah i think you see you've got the resource path there oh my gosh everybody this is just embarrassing let's pretend i've been drinking hold on i know it's only 8 pm for me did you save before you i did press save on that one okay there we go okay yeah so so here's the problem it says success and it's completed as if everything was fine and dandy but i know for a fact that it's returning a fortune wait uh yeah let's see that's not the there's steps let's go down here yeah let's look at the status code method uh yes yeah 14. 429 but it's returning as a complete so that's the pro that's one of the problems now so this is even worse than if it um um in this case because it actually looks like it worked and so your flow would continue on as if everything was fine and dandy so especially in that use case earlier that we were saying where um uh it's like your flow is trying to integrate with another system and requisition access it's gonna look like it's complete and so here um here's why retry policies are good for um to account for uh if that if the api says that is a potential thing that might show up so let's go ahead and add that retry policy now now we're cooking with gas everybody yeah um so here's the recheck policy that i configured earlier i'm gonna go ahead and save it again and now let's test it all right here it is and you'll see that it's waiting see automatically it's already waiting um to see what's it didn't actually complete right away because there is a uh a step currently awaiting a retry perfect and if i go down here you'll notice there is um a new section called retry info um this is updated for san diego so anytime you have a retry policy it it adds this section into your your operations log to let you know that hey we're waiting for um a certain amount of time then here's the next retry here's how many times we've actually retried from here uh and then if i press refresh it hasn't been 30 seconds let's see there now now it moves into complete because it retried after that um again you still need to factor in what you might do if you see encounter one of these um a retry after instead of just testing for it um but if i show you what it looks like on the api side so um i have a again i'm just saying return of 429 and then set the header as retry after for 10 seconds um there is um nuances that you want to remember within retry after policies you want to remember that it needs to be in two form it accepts two formats an integer of seconds so retry in 10 seconds retry in 20 seconds retry 30 seconds or um there's a specific http uh date and time format that you can provide in the header um that some apis can provide and servicenow knows to re interpret that as a um not in a certain amount of seconds but at an exact time i'm allowed to retry um this is really good for like uh like api down for maintenance um they know it's not going to be in a certain amount of seconds it's going to be at a specific time when it's back up and so you know servicenow knows how to interpret that if it's at any um incorrect thing like if i say 10 here or if i put like negative 10 say like retry in the like from the future no uh it'll error it'll actually error out and um you'll see those errors within your system log not in flow designer but within your system log it shows up as a an error there or it might be a warning i think it's a warning um but yeah that's that's like that's how you configure and you um get a retry policy retry after policy strategy running within um flow designer within integration hub uh the next thing i want to show i mean well do you guys want to see no nobody wants to watch me malform this and uh go to system log to see a warning or hey we could just skip past that yeah i i think that's pretty mundane yeah let's see this thing uh let's see this thing work yeah um well let's just assuming that's where you're going next i mean i mean i just showed it that would work that um so when you have a retry policy on retry after policy on um it hits that 429 and then it starts waiting for the next time for it to be available so that's it's showing it working nice i'm gonna say this is gonna be a short episode um the last thing i want i wanted to show well was also so it's the retry policy the new operation section and then the system property so it doesn't um it doesn't exist in your instance until you create it but uh i created it earlier if you create this system property glide.fdih.retry.max time in seconds the default value for it if you leave it blank is 80 is uh i believe this is one day um you could put it to a max of seven days so whatever seven days times seven times eighty six thousand four hundred um but you can also do things like uh so say my retry after policy um was retry after a minute um uh or that's the max time i allowed for a minute on there um i can also set it by system properties saying actually no retry policies can go past 30 seconds and if i set that here and save it even if i have a retry policy where is that even if i have a retry policy uh retry after policy of um with a max of 60 seconds that system property will say no uh we don't want it to go earlier than that oh it should not exceed 30 seconds yeah so you can set it by system property to be 10 seconds also and any retry um after policy that tries to go longer than that will uh automatically um kick back and say nope i don't want it it says and it'll show up in your system luck that's awesome so that's almost from a like an admin perspective of saying like hey this instance will never accept anything over you know a day or something like that and then on the reprise strategy individually you can actually say hey no i don't want anything over like an hour or something like that so you could actually like granularly on on each each level right and i was actually going to ask this question and already answered it because of this is you know if you're taking that that 429 header and you're just dumping it straight into your retry policy and saying hey just wait this long right what you've done is you've moved control of that flow let's say to that api so if i was a nefarious person right and i said now i'm going to make all of my api return you know 10 10 years or something and all and hahaha all of your flows are now locked um right this is your way of preventing that of setting this value and making sure that nobody accidentally sets you know the wrong value at an api and you've got flows that are running for 10 years right exactly yeah so um it's it's good it there's already is um it's already safe uh and defaulting to one day max without any system property but if you want to um fine-tune that you can always make that system property uh again just check the docs it's all sitting there um in the san diego release if you need to look up what name it um or pause the video here and make your policy uh make your system property and change it remember that's in values of seconds yeah that's retry policy retry after strategy in a nutshell it's pretty simple it's pretty straightforward we knew today's episode was going to be pretty um solid because it's like something that we it's one of those things that in http rest in soap world we know we encounter it every once in a while so it's good that it's here um uh not necessarily a pretty and um sexy feature for san diego but it's like when when you live in integration hub world and you potentially could hit every single status code out there um besides what's that the some of the funnier ones no status codes pot 518 i think it is yeah uh something's cooking the pot still or something yeah yeah um yeah good apis have good reasons for every status code and so you might hit some of those things and now servicenow is slowly um getting to parity with all those things that might be out there um uh things that we need to you know be the the full integration system which is what i'm really i i i mean that's one of the things that gets me excited for servicenow future is that it's becoming more and more um it's not like we're i remember talking about this with somebody it's not necessarily that there's other companies that like to buy up a lot of other companies just like left and right to fill out things servicenow is more just like hey we're partnering pretty much with everybody so servicenow is going to be everywhere it is everywhere um and it's these kind of integrations and i mean ways to set it up easier that makes it possible to your point right setting it up easier right like no js let's just talk like for like let's just go on a different programming path right we don't there's no there's no parallel to this right you have to handle this yourself so the caching the retries the holding on to something and waiting for that long which we all know computers are really bad at right you have to do that yourself this is another tool that the the platform has abstracted away from us that we don't have to worry about that anymore as developers that's what makes me super excited it's like yeah this was this was a problem right this was a problem for every project i've ever integrated anything with on anything other than servicenow up to this point right yeah that i mean like that's why we like servicenow is a low code platform but we just shouldn't be shying away from things that are called loca like think about re retry after policy how annoying a scripting that is because the http standard says you either have to be a positive integer or a date time at home and then you have to factor in what you do after a certain amount of retries is there a maximum amount of times before you um cancel it out um can a individual retry have more than 30 seconds what if it goes more than one day we're retrying every 30 seconds when does it cancel you would have to script and figure out all that stuff and now like what mark said servicenow has abstracted that away and said that is now a low code feature yeah now i don't ever have to think about that again and yeah anybody else that's been on the platform for x amount of years you're like oh yeah i remember back in the day we had to do that manually yeah that's every every release we're moving away from that and i think i think of like back in the day like how much time was spent doing manual labor or doing specific stuff and then now we have technology and now we are able to not think about some of the tedious stuff and think about the more fun stuff or the more complex stuff or the more creative stuff and focus and focus on that while servicenow takes care of the easy easy stuff no service not takes care of the hard stuff that's right doing the easy stuff yeah yeah awesome well thanks uh thanks earl for uh leading that and showing us retry policies that was great um yeah so we've got another show on friday afternoon u.s time uh live coding happy hour where we are going to talk what are we imports is that what we're doing uh excel imports via app engine studio yeah uh integration hub app engine studio excel imports bringing it all together um awesome all right well thanks everybody for joining us do you have an announcement errol um i'm about to go release um several hundred mentorship pairs to the wall right so i'm gonna go press that big button if you sign up for the mentorship program expect an email uh from us so yeah uh not everyone expect an email the one that we were able to find pairs for the people that matched that's fair several hundred though all right well thanks everybody for joining and we'll see you on friday for live coding happy hour talking more integration hub thanks everybody have a great day [Music] you