How Web Services Automation Streamlines Your Enterprise

Thank you for joining me today to talk about automating web services. My name is Pat Cameron. I'm the Director of Automation Technology here at HelpSystems. I've been with HelpSystems about over 16 years. Oh my gosh, over 16 years. In a previous life, I was an Operations Manager at a hospital here in Minnesota, where we're located.

We kind of feel your pain on the operations side of IT. We are going to talk about web services today. So what is it? And I'll be honest with you, I haven't worked with web services probably over the past year that I've become familiar with it, and what it can do for you. And so we're going to talk about some of those things. Why would you want to automate those web service requests? And then with our HelpSystems Skybot product, I've got some examples of how you can automate some of your web service requests.

Nice to see some customers' names out there. Thank you for joining today, and then also some new people that aren't so familiar, so thank you as well.

This is a typical business process that just about anybody runs in their IT department: your CRM where all of your customer information is stored feeds into your data warehouse eventually. Orders, contracts, payments… all of that data needs to come from your CRM or from your order entry system or from your website, and eventually go through your ETL system so that it's matched correctly. And then sent to your data warehouse where reporting begins.

Also your ERP system has inventory levels, accounting information, your planning, etc. So all of those different systems can be written, they can be disparate systems, they can be on different systems, they can be spread out throughout your organization, actually. And before web services were available, somebody had to write interfaces between those applications and your ETL system, for example.

And so when web services came into being a number of years ago now, what it did is it kind of streamlined that process. So instead of having to write an interface for different departments within your organization to access that data, they could use one, which was a web service and one of the beautiful things about the web services: there's no client that you have to install on your work station, you don't have to download anything. You can access those services through the web.

So web services is just a piece of code that's made available on a machine that's connected to the internet. The web part of web service defines the method by which it's accessed--through the web--and the service part relates to the idea of providing that access and functionality without having to create our client, install a client on your workstation. Since it's run on the web, it can be accessed by any machine that's connected to the Internet and that machine. It has to be able to authenticate to it--not just anybody can access it.

Well, some web services anybody can, actually, and I've got some examples of that. So what it's done is it has created a standardized protocol that can be accessed from any environment, by any environment. So it really streamlines the work that your developers have to do. The user, when they access that data, only sees the final result. They only see the data that they need. They don't see the process that goes into providing that data, and frankly, they don't really care.

So why would you want to leverage web services? And I think the big answer is because of the efficiency. Most of the companies, there is some type of a duplication in functionality based on those various environments. For example, if you need to retrieve a piece of information, that process of accessing it from your development team might be different than how accounting accesses it or how the HR department accesses it. And assuming that this information can be accessed by a web service, you'd only have to require a single interface and eliminate the need to have to develop and maintain disparate systems.

So it increases the productivity of your developers and your users--everybody uses the same interface--there's typically a quick ROI because of that. Like I said--simplifies and streamlines development. And web service can be used for business-to-business integration or application-to-application. So I use web service when I go to FedEx and track all those boxes that I'm getting from Amazon these days. So FedEx, UPS, the post office, etc., that's all a web service that you log into to track your packages. Now all you've got to know is that tracking number, and what you get back as a result or the response from the web service is that tracking information--where is that package. You can also access your bank account, you can make airline reservations, etc. All of that now is accessed through a web service.

Within your company, within the applications that you're running, again, the CRM orders need to be sent to ERP for your inventory level, the distribution center also needs to access those inventory levels. So as a web service, you can have one interface that either a user might be accessing it or program-to-program can be accessing it as well. So that's kind of what a web service is. It makes life a lot easier for developers and for people that have to access data.

Let's take a look at how Skybot can automate some of those processes for you and take a look at some examples of how web services can be used. I've got a few little examples that I'm going to bring up shortly.

Inventory levels, again. I just talked about it. Stock prices and currency rates, these are web services. So I'm using some examples of web services that are free and available out on the web, and you can create examples for testing in your environment if you need to. So, stock prices. Maybe you want to update your stock price for your company on your internal website and you want to update that maybe hourly.

So what you can do is you can use a web service and a Skybot job to automate that process. Go out, grab the recent stock price, pull it in--maybe in an XML format--and then push that up to your website, and Skybot can automate all of those different steps within that task. Currency rates. Before you send out invoices that night, you want to know what the exchange rate is. And so you can use a web service as the first step in your nightly processing that's going to be sending out and creating invoices. Again, you get a response back with what that exchange rate is in any format that you need it, and then push that out to your invoicing application and now that the process can go on with the correct exchange rate.

So how Skybot does that is: we have an object that you can use that is a built-in function that allows you to define any of the web servers that are available to you or that you have within your organization. Define those base URLs and how you're going to authenticate to that. And you set that up as a one-time setup within Skybot and then you can use that to build a web service request. We provide a little template that you can use for that request and then you can schedule that as a Skybot job. So you can go out periodically and pull those stock prices down if you want to. So this is what our template looks like for that currency converter. So here is our web server definition that we've set. This is just webservicex.net. Again this is a web service that's out there in the Internet that you can use.

Create some variables. Here, I've got a “from” and a “to” currency. So Skybot can handle those variables and you can update those with another web service call and change it every time that job runs if you need to. Here's our base URL that we pulled in and then this is the application. So this is what we're actually going to be doing with this web service is using the conversion rate, URL, or application. The type of request, this is a GET request so we're going to get that information and then over here we've got the parameters. And we've defined the “from” currency as the British pound and “to” as the U.S. dollar. And so we want to get that exchange rate for those two currencies. And then we're going to output that information to an XML file which again can be fed into your invoicing application.

Another example is first the stock prices. So again, there's another application out there on webservicex.net for stock quotes, and it's got a parameter of the stock name. So which stock name do you want to pull in? And again, you could use it for reporting, you could use it to put it up on your website for your stocks. And I'm outputting this as an XML file as well, and I'm going to use that variable to name the file because I might want to get multiple company stock quotes. Okay, and my mouse isn't working here. So along with being able to provide a built-in function to be able to use web services that are provided by other providers, we also provide a web service within Skybot.

So we provide a restful web service and this is the base URL for that web service. There's a flag that you can set up in the Skybot system settings to turn it on. You can use basic authentication or you can use HTTPS for secure connection to that web service. And then you can construct the requests using a web service client that you might have, or using your application. And I'll show you an example of that as well.

So some of the things that we can do with our web service is we can manipulate Skybot jobs. You can use it to create new Skybot jobs, and we do have some customers that are using it to create a new Skybot job, and sometimes they're using... you can create a template job and then edit that. We can push out all of the information about that job into an XML file and then you can edit that or you can edit it with your program to create a new job. This could be used to create temporary jobs. I know one of our programmers uses it to create hundreds of jobs for testing and uses a web service application to do that.

You can use it to manage job queues. So if you want to hold or release job queues at certain times and you want to do it through your application, maybe your users use that as an interactive user interface. They could trigger a web service that would manage the job queues, stop and start agents if needed, enable and disable event monitors. I know we had some customers that don't want to run those event monitors 24/7, so you can use a web service to enable or disable them.

You can also create lists of information using our web service. So I could pull a list of all the job history, maybe just all the failures. There's a lot of different parameters that you can use and push that out to my web interface or to my internet that operation is using, and you can automatically have that update as often as you want to. Again, if you've got people that don't have access to Skybot but yet they want some of that information, maybe your executives, you want to push it out to your dashboard, and you can automatically update that at whatever interval that you want to update it at.

So you can use it to kind of manipulate Skybot jobs, run jobs, put jobs on hold, etc. So a couple of ways that you can use it: we do have a command line interface and I've had a number of people recently that want to use a command line instead of the browser interface for creating jobs, etc., because they're more comfortable with the keyboard. So you can certainly do that using the web service. Push that job definition out into an XML file, edit it, and then create the job with the web services well. So these are some of the parameters on our job services as a BAT file because I've got a Windows server, so I'm using that but there's the same commands are available in Linux or Unix and shell scripts.

And all you've got to do is remember to go to the system settings in Skybot and allow web service requests. When Skybot is shipped, that's turned off. So if you want to use our web services, go ahead and turn that on and then it will be available and you'll have the link to the web service.

I use this little Fiddler client for doing some testing and setting up examples. And here we've got the link and the URL to my web service, Skybot8008. We don't have it... we're not using it secure because it's just used in-house, and it's running a job. And so here is my request: I'm going to run a job and then down here, I've got the response from the web service. And again, this is something that you could push out to a website if you needed to. Hugh is asking if there's an API for a Python job or a Ruby, yes there is. You can use any of those coding languages that have that web service available. I think I was talking to the tester yesterday and he uses Ruby most of the time.

So some examples of why you would use this: you can create new jobs through your web service. We have a customer that's requiring that. They have an application that they use that kind of sits on top of all of their batch and they want users to be able to create those jobs through that web service. So that's the interface that they're using instead of logging into Skybot. You can create those jobs programmatically using that web service and then you can push those lists of job history out to your dashboard. Lists of job history, job set up, any kind of information, calendars, variables, notification lists, any objects that are within the Skybot if you need to push that information out, typically you can. History is probably the one that's used most commonly.

Sometimes you want to hold and release jobs on a schedule. Before you go down for maintenance, you want to hold the queue or you want to hold a number of jobs. You can set up a web service that will go ahead and do that, and you could set that up as another Skybot job actually and then schedule that job to hold a bunch of other Skybot jobs or hold the job queue within Skybot. So that's the nice thing about the web service that we've got. You can either use it through your interface or you can use it within Skybot. And we found a lot of users to be able to hold other Skybot jobs and release them. You can also run a job and you can change the parameters that it runs in, or you can even overwrite the job name. So you can create a bunch of temporary jobs if you need to by running a job with new parameters and a new job name. So you will start with the template, and then you go ahead and manage it with a web service.

So let's take a look at some examples. I'm going to go online and just show you a couple of examples that I've got set up. So this is my interface to Skybot, and what I'm looking at here is a list of the web server definitions that we've got here. And this is the one that I'm using today, this webservicex. You can see we've got some for Dynamics, some Crystal. Again, any web service that's available we can work with. So you enter in the base URL, the character set that you're using, the type of authentication (and this one doesn't require any.) So I just store that information once, and then you can set those up in a Skybot job.

So I'm going to go to the Skybot jobs that I have. So these are the jobs that I've got set up for web service, and here's my famous currency job, and I'll just show you what the command line looks like. So scheduling can be done just like any other Skybot job. I do have a couple of variables that are defined here, the British pound and the U.S. dollar, of course. Those can be changed and they can be changed with the web service command. So in order to schedule one of those, you just do web service request and then we pop up this template and you fill in the details. So there's a list of all my available web servers, my webservicex here and my parameters. Here's the application URL and that's pulled from the website, where the webservicex live. The request method, fill that in, the parameters, again the pound and the dollar. And then here is where I'm spending the body of the response to an XML file that I've got over on my PC.

All of the scheduling can be just like any other Skybot job, any dependencies that you have. You can add other commands to this job if you want to. So if I run this, I'll bring my little folder over here. I'll go ahead and run this job, and here's the output from that job. Here's my conversion rate XML. So if I open that one dot, a dollar and a half--and I found that out, I'm planning a trip to London over Christmas, and this is pretty painful--but what you can do is you can take this now and pass that to your invoicing program or to whatever needs to run next. Now you've got the correct and current currency rates.

Same thing works for stock. Take a look at this. For stock quotes, if we take a look at this I think we've got one variable that's defined, the stock name, and we're getting Apple information. And here is where the parameters are listed for that web service request. Again, we're using the same web service, but we're using a different application so we're using the stock quote instead of the currency rates. And these are my parameters, and I'm setting them in the Skybot job, and then for my output I can output based on the stock name so I can change the name of the XML file. So I could run that for Apple. Let me run that for Apple, and then I'll show you. Go ahead and run that, and then we'll take a look at the output.

And then I can also run it and change that parameter, change that variable. So here, the stock name is… let's do GOOG and we'll go ahead and run that. And now if I go back to where my output is coming, here's my Apple XML. Depending on what their response is from the web service, certainly you might get more information that you need, but you can parse this into just the few that you need and send that to your website. And then here's the one for Google. So you can change the parameters on the fly, you can change the parameters within your web service depending on how you want to pull that information. And then one other that I wanted to show you…so those are using another provider's web services as examples.

Now this job uses Skybot's web service and I'm doing this through a Skybot job, but I'll show you in just a second using my web service client as well. So if I use it through a Skybot job we do have commands that you can use and what this job is doing is it's listing the job information. So here, we've got the URL, I've got my credentials in a file that's secured or doesn't display, the type of information that I'm getting is job information. I'm just going to get the information that's defined in this job, this setup for my job, the name of my job, and then I'm sending that out to my temporary directory as well.

So if I run this list job, it's going to create an XML file that's going to show all of the information needed to create a new Skybot job. So now I can take the results. Here’s the job name, here's the description, and if I just scroll down, here are all the different parameters that you can add to a Skybot job. They certainly aren't all required as you can see, but now you can update them and change them, feed them to another application. If I go to the command, here we go. So here I've got the command information and it just does this way .BAT that I've got in certain way. So now I can take this and feed this into another web service request to create other jobs that are like that one, maybe change a parameter, change the job name, etc. But you can do that using a command line then.

So we have another job here that has parameters. I'm just going to show you this one, and then I'm going to run this job from my web service clients. It runs a program, a BAT file that I've got that's got two parameters, PARM and PARM2. And up here, I've got those defined in the Skybot job, and they just have default values. I can run that using my web service client here. I'll go over to job history and we'll kind of watch that run. So here I've got Fiddler--it's a little web client that you can use for testing or running web service commands. And I've got a command kind of queued up here so this is my web service command. It's going to run the job with PARM and then the parameter that's changing to region and district, so I've got those set. So it's going to overwrite what's in that command.

So if I go ahead and execute this command… here I've got the authorization, the authentication, in order to log into the web service. I'm going to go ahead and execute that, and then up here, that job WPARM submitted, and here I've got the run numbers. So that's what get sent back to your web server. Here I've got the run number, the agent name, and the job name. And here if I refresh my history, here's where that job ran. And so I ran that from my web server client and also if we take a look at the parameters for that command down here, my program just does a little hello, and here's where it substituted region and district for that parameter. So you can use your web server to run Skybot jobs using your web service client or you can wrap it in a program with Ruby or Python or one of those languages.

A couple other examples that I've got here… let me bring up my job queue. I'll just show you that I can… so I've got a number of different job queues here and I think this one puts my single thread on hold. So if I take a look at this command, again my web service, it's an agent type, and I'm holding job queue single thread. And so if I go ahead and execute this and then refresh this screen, you can see that that single thread job queue is put on hold, and then I've got another command queued up to release it. So I'll release it. If I look at the response, it will tell me that that's been released. And if I refresh it, it will show you that it was released.

And then the last thing that I wanted to show you is how to get those history records from Skybot and send them to maybe a website, your dashboard. And so we've got a parameter here for job histories and it's got different parameters that you can put on it. I'm going to limit it to just 10 and for the status, I only want failures. So I want the 10 most recent failures. So this is something that you could schedule, and it could be updated and pushed out to your dashboard as often as you need it to be updated. So I'll go ahead and execute that command. And now if I take a look at it, here is the response, and here's the XML version. So this is the date and the time, this is the agent, here is the run ID and it was a failure. So here is the job name: SMMP send trap. And if I scroll down, again you're going to get the start and the end time. You'll get the status. Here's my status of an F and it translates to fail. So whatever it is that you need that you want to push up to your dashboard, it’s very easy to get from this XML file that gets created by Skybot.

So those are just a few examples of using a web service within Skybot or using a web service that you have to manipulate Skybot jobs. I've got a couple of questions here. Let me see if I can... Okay. So we covered Python, Java and Ruby. I've got a job I want to assign to another support rep in case it fails and I'm not in the office. Would I be able to use the web service so he can run the job? Absolutely. You could create a web service through your user interface that would do a run job for just that job and then you could run it under his user profile so a part of the config is how to authenticate to that server in order to run that job. My jobs are running under my profile. You could add him to a role within Skybot and only have access to that one job and only have execute so you really can't change it to however you want to. But yeah, certainly you could do that.

He was asking if Skybot can...Can Skybot convert any XML into JSON? You know Skybot… sure, your output… I think your output could be JSON. I just selected to output as XML. We do use a JSON format in our import and export center, so if you use the export to export a Skybot job it will export to a JSON formatted file that then you can use in our import center. Customers use that usually for moving from test to production, to export and the import. Yeah, certainly.

All right, I'm a minute over. I hate to go late. Any other questions? Hopefully you've got a little taste of Skybot, its web service, and how you can use Skybot with your web service. Well, thanks for joining us today. I appreciate you taking the time to take a look at Skybot, and I want to thank all those Skybot customers out there. We really appreciate you using our products. Have a good day everyone and we'll see you next time.